这篇其实在问一个更商业的问题

如果你把这两年的 AI 讨论听多了，会很容易形成一种默认视角：最核心的竞争，发生在模型公司之间。谁参数更强，谁 benchmark 更高，谁先发了新能力，谁就站在舞台中央。

swyx 这篇做的事情，是把镜头往旁边挪了一下。它在问另一件事：真正贴着用户、贴着任务、贴着业务结果长出来的公司，未必还是卖模型的人，也可能是那些最会把模型做进工作流的人。

这个问题一旦问出来，很多事情会突然变得更现实。

用户最终买的，很少是模型本身

开发者平时很容易被模型能力吸走注意力，因为那是最容易看见、最容易对比的部分。但用户决定掏钱时，想的通常是“这个系统到底帮我省了多少活”，而不是“这个模型是不是第一名”。

一个会搜仓库、改代码、跑测试、提交 PR 的工程 agent，它的商业价值往往并不只来自底模本身，而来自整条任务链到底有多顺、失败时能不能救回来、是不是能长期用。

这就是 swyx 想把大家从“模型排行”拉回“任务完成”的原因。

对开发者来说，这会改写你看产品的方式

如果你是开发者，这篇最有用的地方，是它会逼你跳出“接模型 API 就是在做 AI 产品”的错觉。

以后更值钱的，往往是端到端完成率，不只是单点能力。你得开始关心这些东西。

• 任务到底能不能闭环。
• 工具接得稳不稳。
• 失败之后怎么恢复。
• 用户到底在哪一步开始觉得它真有用。

这让开发者的视角从“做功能”慢慢变成“做结果”。

比如同样是“帮用户写文档”，一个产品只是多了个生成按钮，另一个产品却能读仓库、抽改动、生成初稿、回填格式、再交给人审批。两者看起来都沾了 AI，但真正更接近 Agent 公司卖法的，是后者这种“把结果交出来”的产品。

产品和测试会更先感受到这种变化

产品做 AI 功能时，很容易停在“我们接哪个模型”这一层，因为这层最显眼，也最容易汇报。但这篇会迫使你多问一句：用户真正买的，到底是模型能力，还是结果交付？

测试也会比很多人更早看到另一层现实。一个 agent 产品测的已经不是单个页面和按钮，重心会转到整条任务链。它中途会不会断、错了会不会自我放大、系统能不能把自己刚才做的事解释清楚，这些都开始变成主测试对象。

从这个角度看，产品和测试其实比很多人更早站在“Agent 公司”的入口上。

最有带入感的场景，其实就在企业内部。一个“帮销售填 CRM”的功能，如果只是生成一段跟进建议，它还是助手；如果它能读通话纪要、抽关键字段、回填 CRM、提醒下一步、把异常记录丢给销售确认，它就已经开始长出 Agent 公司的味道了。用户为这种东西买单，往往是因为它真帮人少做了四五步，不是因为它模型第一。

对 Agent Engineer 来说，护城河开始变地方了

这篇对 Agent Engineer 的启发很直接：真正要构建的，是可交付的任务系统，不只是会说话的模型外壳。

很多团队会把注意力放在模型接入和提示词技巧上，但更容易长护城河的部分，往往在 orchestration、tooling、eval、memory、权限边界和真实场景适配上。

换句话说，Agent Engineer 也越来越像一类更贴近产品交付的系统工程师。你的工作不只是把能力展示出来，还要把结果稳定交出去。

一个很适合马上做的拆解练习

拿你们现在最想做的一个 AI 功能，强迫自己把它拆成四层写下来：模型、工具、工作流、最终结果。

如果你们现在讨论得最多的仍然是第一层，那就说明这件事还停留在“接能力”的阶段；只有当讨论开始往后三层移动，它才真正开始接近一个 agent 产品。

更新附注

• 版本：v1.1
• 更新日期：2026-03-20
• 更新原因：为系列文章补充统一阅读序号，帮助读者更自然地衔接到产品与商业层讨论。