Agent 落地这一年：从 Demo 到 P&L

过去一年我看过几十个 Agent 项目，从大厂内部工具到创业公司的产品，从跑通演示到跑不进生产。结论比想象中简单：Agent 的技术门槛在快速下降，商业门槛几乎没变。

演示和交付之间隔着一整套脏活

一个能演示的 Agent，只需要三样东西：一个模型、一段提示词、一个看起来合理的界面。这三样在今天都是低成本的。

一个能交付的 Agent，需要的是另外三样：

• 确定的输入边界 —— 它读什么数据、不读什么数据、脏数据怎么处理
• 可判定的对错标准 —— 什么叫做对了，做错了谁来兜底，错了之后流程怎么回滚
• 可核算的成本结构 —— 单次调用多少钱，一天跑多少次，成本随量增长还是随人增长

这三样没有一样是模型能帮你解决的。它们是工程问题、流程问题和会计问题。

大部分停留在 Demo 阶段的 Agent，不是技术不够，是没人愿意为「确定边界」这部分付钱。

判断标准：它替代的是工时，还是搬运了工时

我用一个很土的标准判断一个 Agent 值不值得做：看它减少了谁的工时，还是增加了谁的工时。

很多项目上线后，业务人员的实际动作是：打开 Agent → 拿到结果 → 逐条核对 → 手动修正 → 提交系统。Agent 把「写」的环节自动化了，但把「核对」的环节变成了一道新工序。总工时没下降，只是从一个人身上转移到了另一个人身上，还多了一次上下文切换。

真正成立的 Agent 有一个共同特征：它的输出不需要人逐条核对，只需要人抽检。 要做到这一点，通常需要把任务的判定标准先写清楚——而这恰恰是最难、也最值钱的部分。

定价的错位

第二个普遍问题是定价口径。

按调用次数收费，客户会压量；按席位收费，客户会质疑为什么用了 AI 还要按人头付钱；按结果收费，双方会在「什么算结果」上吵三个月。

目前我看到相对稳的一种做法是按被替代的工时包定价：先测出人工完成一次任务的平均耗时和年频次，折算出年度工时成本，按这个基数的一个比例报价，并约定效果不达标的处理方式。它不完美，但至少让双方在同一张表上讨论问题。

接下来一年我看什么

三件事：

1. 判定标准的工程化 —— 谁把「什么叫做对了」这件事做成可配置、可复用的组件，谁就拿到了议价权
2. 成本的边际递减 —— 模型调用成本能否降到让长链路任务在经济上成立
3. 责任边界的产品化 —— 出错时怎么追溯、怎么赔付，会从合同条款变成产品功能

技术会继续进步，但真正决定谁能活下来的，还是这三件不那么性感的事。