烧了几百亿Token重写网关之后，他说：AI的能力早就溢出了，跟不上的是人
2026年春节，API7.ai创始人温铭团队在Apache APISIX上撞了一个怎么也复现不了的bug。读了几轮代码无果后，他们把问题现象描述给了一个AI Agent——不到10分钟，仅靠静态代码分析和现象描述，Agent就准确指出了问题所在。
"那一刻，真的把我惊艳到了。"温铭在InfoQ上发表的文章中回忆道。但这只是他个人AI实验的序幕。此后一两个月，他烧掉了几百亿Token，用AI从零重写了一个生产级AI网关AISIX，并在公司内部推行了一条颇具争议的规则：尽量不手写代码。
InfoQ在6月26日发布了这篇题为《烧了几百亿Token，我用AI重写了生产级网关，总结出6条经验》的长文。以下为转载核心内容，并结合我们在Agent、MCP与技能仓库建设中的同类体感，做一些延伸讨论。
一、AI接管了打字，但没接管你脑子里的那张图
温铭的第一个判断直接而锋利：AI看得到What、能完成How，但Why还得人自己来。
他解释说，你看Apache APISIX看到的是一个成品，但它中间的思考过程、概念抽象、架构设计——这些背后的"为什么"——从来没有被很好地写进任何公开知识库。AI能看懂代码长什么样，也能照着写出来，但在对Why的理解、判断和抉择上，和资深工程师比仍有不小的偏差。“说白了，它接管的是打字，没接管我脑子里的那张图。”
这个判断和我们做Agent Skill Warehouse过程中的体感完全一致。技能仓库里BA-Master、SA-Master、PM-Master这些Skillset，真正难的不是"让AI写出一份PRD"——这件事哪个大模型都能做。难的是让AI在写之前，先通过渐进式提问把根目的、异常分支、合规约束逐一澄清，形成一份"每一行都被验证过"的文档。这个过程对应的，正是温铭所说的"脑子里那张图"——它不能靠模型一次生成，而是靠人和Agent的多轮交互，一步一步收敛出来的。
二、"禁止手写代码"引来的反弹，暴露的是组织惯性
温铭在公司做了一个决定：尽量不手写代码，把"打字"这件事交给AI Agent。反弹最厉害的，恰恰是最资深的那批工程师——他们认定，vibe coding做出来的只能是玩具。
这背后有一个更深的组织命题。温铭观察到，反弹大的人往往是那些把自己定位得特别清晰的工程师——“我是前端”“我是后端”。一旦你把自己框死在某个角色里，AI这种能轻松打破边界的工具反而会让你不适应。他举了自己的例子：一个基本没写过前端的人，靠说清楚配色、CDN、移动端适配这些评判标准，就能做出还不错的Dashboard。“这对产品的定义和迭代来说，是个很不一样的视角。”
我们在推广Agent Skill Warehouse的过程中，遇到的是同一类问题。不是技术问题——是"领地意识"问题。BA习惯了自己写PRD、SA习惯了自己画架构图、PM习惯了自己排期。当一套Agent Skillset能把BA的需求澄清、SA的七维度架构确认、PM的跨角色编排做成标准化能力时，第一反应往往不是"太好了"，而是"那我的价值在哪"。
温铭给团队的建议值得参考：你可以不同意，但请用最好的大模型，放手让它去做——这样你才知道它的边界在哪。
三、是玩具还是生产级，这条线画在人身上
"经常有人问我：哪些代码能交给AI，哪些不能？我觉得这个问题本身就问偏了。"温铭说，比起区分代码类型，更核心的标准是——指挥AI的这个人，对架构、代码、测试有没有清晰的理解？对把东西推上生产，有没有一颗敬畏之心？
他给自己定了一条原则：这个决定你要是看不懂，那就一定别做。 因为哪怕AI的决策正确率达到85%到90%，剩下那10%也足以让整个项目的质量大幅下降。
这恰好解释了为什么Skill不能只是一段"增强提示词"。在Agent Skill Warehouse的实践中，一个合格的Skill必须有四层结构：指令层决定何时触发，知识层提供执行上下文，执行层做确定性校验，评测层闭合反馈。其中最关键的是评测层——每个测试用例跑两遍，一遍带Skill、一遍不带，用数据回答"这个Skill到底有没有用"。温铭说的"敬畏之心"，在Skill层面对应的就是这套对照评测机制：不是凭感觉说"AI变强了"，而是拿证据说话。
四、AI写的代码，得再用一个AI去review——治理需要闭环
温铭团队的做法是：用Claude Code写，写完之后冷启动一个全新的、独立的AI Agent去审计PR，同时再用CodeRabbit和GitHub Copilot做第二层。AI写出来的代码，至少要换一个不同的AI去review。
这恰好是我们在技能仓库治理中反复强调的"审计闭环"逻辑。Uber在Agent身份治理上的实践给出了一个方向：通过"参与者链"让每一次工具调用都可追溯到"谁最初发起、中间经过了哪些Agent"。把这个思路平移到Skill层面——当Agent通过Skill A调用Skill B时，授权决策应该能追溯整个链：原始用户→Agent→Skill A→Skill B，每一层的权限应该逐级收窄而非逐级放大。
温铭用"AI审AI"保证代码质量，我们主张用"Skill的声明边界与执行轨迹的自动化比对"保证能力治理——本质上是同一件事：在AI加速的系统中，人的肉眼已经追不上产出的速度了，必须把治理本身也自动化。
五、为什么需要一个新的AI网关：基础设施的逻辑变了
文章后半段，温铭解释了为什么要从零重写一个AI网关AISIX，而不是在Apache APISIX上加插件。
两年前他们尝试用APISIX的插件体系代理AI流量——限流限速、负载均衡、fallback、身份认证，看起来API流量和AI流量没什么不同。但做着做着就发现，核心概念根本不一样：API网关的核心是路由、Service、Consumer；AI流量的核心是LLM Provider、虚拟API Key、模型合议、语义路由。硬套进去不是不能做，是不自然。
于是他们用Rust从零写了AISIX，把各家大模型收在一个统一API后面，把token计量、成本控制、多模型负载均衡与fallback、prompt层面安全、流量可观测全部内建到网关里。选Rust的理由也很实在——AI流量大量是长连接的流式输出，需要一个没有GC停顿、单请求开销低、延迟可预测的运行时。
这个决策逻辑，和我们反复强调的"技能仓库为什么不能是一堆SKILL.md文件的共享盘"如出一辙。当Agent数量从几个膨胀到几十个，当Skill从十几条涨到上百条，你会撞上同样的问题：旧基础设施的核心概念，兜不住新场景的真实需求。 技能仓库需要的不只是文件存储，而是版本化管理、可评测的通过率数据、权限策略的逐级传播、执行轨迹的审计闭环——这些能力，靠"加个目录"或"写个插件"是加不出来的，必须重新设计基础设施的底层概念。
六、从网关到仓库：AI基础设施的两块拼图
温铭在文中画了一条个人进化曲线：第一阶段堆框架（各种harness和skill集合），第二阶段扔掉框架、把自己的经验沉淀进一个百行左右的agents.md，第三阶段从"上瘾式编码"转向"高质量决策"——并行五六个任务，一天做四五十个决策，把精力压在上午到下午三四点之间，晚上和周末尽量不碰AI。
“烧1亿还是100亿token，真不是关键。关键是两件事：你的经验有没有沉淀进那个md文件，你的高质量决策能不能高效地做出来。”
这段话恰好揭示了AI网关和技能仓库之间的互补关系。网关管的是流量的入口——模型调度、成本控制、安全防护、可观测；仓库管的是能力的出口——Skill的发现、评测、权限、生命周期。 两者叠加，才构成企业AI基础设施的完整轮廓：流量进入网关，被路由、计量、保护；能力从仓库加载，被Agent按需发现、按策略调用、按证据审计。
温铭说AI的能力早就溢出了，跟不上的是人。我们想补充的是，让人跟上的方式，不是让每个人变得更聪明，而是把人的经验结构化为Agent可以加载的Skill，把治理逻辑编码为平台自动执行的策略，把"脑子里的图"变成可复用、可迭代的工程资产。 让人从重复决策中抽身，聚焦那些真正需要人类判断力的Why——这才是Agent基础设施的意义。
转载说明： 本文核心内容转载自InfoQ 2026年6月26日发布的《API7.ai创始人温铭：烧了几百亿Token，我用AI重写了生产级网关，总结出6条经验》，作者温铭。本文在转载基础上，结合Agent Skill Warehouse在Agent治理、MCP协议落地与技能仓库建设中的实践经验做了延伸讨论。
参考资料：
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
3
0- 0
已为社区贡献5条内容
所有评论(0)