ai agent 和传统软件有什么区别

做产品评审时经常有人问：这东西加个 Agent 是不是就高级了？研发这边却在担心状态、超时、成本怎么控。这篇不吹概念，只把 Agent 和传统软件在确定性、控制流、状态管理、测试验收这几处的真实差别摊开，给一张能直接拿去对齐认知的对照表，再说清楚什么场景压根不该上 Agent。

评审会上常有人问：这个功能加个 Agent 是不是就高级了？研发那边的反应通常是皱眉头——状态放哪、超时怎么控、一轮跑下来成本多少。两边说的其实不是同一件事。传统软件是「你写死的路径，机器照着走」，AI Agent 是「你给个目标和工具箱，它每轮自己决定下一步」。这个差别不是技术选型的偏好问题，它会一路渗透到架构、交互、测试、上线和运维的每个环节。

这篇不聊概念，只把差别摊开成能对齐认知的对照表和清单。目标很具体：产品看完知道自己该在需求里补什么，研发看完知道哪些地方不能再套原来的经验。同时也会说清楚哪些场景压根不该上 Agent，省得为了赶时髦把一个本来三天能写完的东西拖成三个月。

控制流从「写死」变成「运行时决定」

传统软件的分支在编码期就定死了，if 到 else 的路径是确定的，同一个输入跑一百次结果一样。Agent 不一样，它每一轮都要根据当前上下文挑下一步：调哪个工具、要不要再问一句、是不是该收尾了。同一个输入跑两次，路径可能完全不同。这不是 bug，是这类系统的固有属性，你得接受它然后再去设计约束。

直接后果是验收标准得换。别再写「输入 A 必得输出 B」，改写成「结果落在可接受集合内」。比如一个整理会议纪要的 Agent，验收标准不该是「输出必须等于某段文字」，而是「待办事项不漏、负责人识别正确、格式符合约定」。达不到这个粒度的验收，测出来全是噪音。

状态管理：数据库之外多了一份「对话上下文」

传统软件的状态几乎都在数据库和缓存里，重启不丢、可查可审计。Agent 的状态一多半在上下文窗口里，窗口一裁、摘要一压，信息就没了。这带来的第一个坑是：你以为存下来的东西，其实只存在于某次调用的内存里，下轮就蒸发。

要明确区分三类东西，别混在一起存。会话历史是短期的、会被压缩的；工具返回值是单次有效的、用完可以丢；长期记忆是跨会话的、需要显式写入和过期策略的。三者的存储位置、生命周期、清理方式完全不同，混着放必然出现「上次说过的事它这次忘了」这种说不清的 bug。

• 会话历史：按轮次或 token 数设上限，超了就摘要压缩，压缩策略要固定且可回归测试
• 工具返回值：默认不进长期存储，只保留关键字段，原始大对象落对象存储并记引用
• 长期记忆：显式写入、带来源和时间，必须有删除入口，否则会越积越脏
• 上下文预算：当预算管，不是当垃圾桶，每一类信息都该有配额，超了就得让路
• 排查入口：日志里要能重建某一轮实际送进模型的内容，不然问题无法复现

上下文当预算管这件事，工程上的具体做法可以参考站内关于上下文预算的文章，那里把压缩和召回的策略讲得更细。这里只强调一句：不设预算的 Agent，成本和质量都会失控。

交互模型：从表单和按钮变成自然语言入口

传统交互的输入空间是有限的，几个字段、几个按钮，前端可以做穷举式校验，非法输入在提交前就拦住了。Agent 的输入近似无限，用户说什么都行，前端没法再做穷举校验。这意味着校验的位置后移了——从「输入时拦住」变成「理解后确认」。

产品上要补的不是更多按钮，而是「意图确认」环节。关键动作执行前，让界面回显一句它理解成了什么：你要取消的是哪一单、要发的是哪个群、金额填的是多少。用户扫一眼就能发现理解错了，比事后补救便宜得多。

1. 先定关键动作列出哪些操作做错了代价高——删除、发送、付款、对外可见的发布，这些必须有确认环节。
2. 回显理解结果用自然语言或结构化摘要把 Agent 的意图展示出来，别只显示「确认？」两个字。
3. 留纠正入口确认环节旁边给「不对，重说」的路径，方便用户直接改口径，而不是从头再来一遍。
4. 高频路径另开把常用操作做成快捷方式或固定入口，自然语言作为兜底，不是唯一路径。

不适用的地方也要说清楚：面向高频重复操作的场景，自然语言反而比点两下慢。收银、批量录入这类场景，自然语言适合做兜底入口，不该当主路径。判断方法很简单——这个操作熟练用户一天要做几十次吗？是的话，按钮优先。

工具调用：Agent 的手脚和有副作用的操作

传统软件调内部函数，同进程、可控、失败模式清楚。Agent 调的是暴露出来的工具，每个工具都是一次可能失败、可能超时、可能重复执行的调用。这三件事在传统调用里也常见，但在 Agent 场景里被放大了，因为调用时机是模型自己决定的，不是你排好的顺序。

最需要提前想清楚的是写操作。读操作失败了大不了重试，写操作重试两次可能就重复下单了。所以写操作类工具必须考虑幂等：给每次调用带一个业务侧生成的唯一键，服务端按这个键去重。同时权限要分开设计，读工具可以放开，写工具要么走二次确认，要么限定金额和范围。

还有一个容易忽略的点：工具返回的内容要瘦身。一个返回几万字的接口，一次就能把上下文冲垮，后面的推理全废。约定好只返回必要字段，多余的落引用，这是工具设计里的硬要求。

测试与验收：从断言输出到断言行为

传统单测断言具体值，跑过了就是过了。Agent 的测试得拆成几层来看：工具有没有被正确调用、参数是否合理、最终结果是否达标。只断言最终结果会漏掉一半问题——结果碰巧对了但路径全错，下一个输入就会崩。

评测用例得攒。改一次提示词、换一次模型、调一次工具描述，都该跑一遍固定的用例集。不跑的话，「感觉变好了」全是错觉，而且这种错觉会一直累积到线上出问题。用例不用一开始就很多，但每修一个 bug 就补一条，慢慢就厚了。

• 行为层：断言该调的工具调了、不该调的没调，参数落在合理范围
• 结果层：断言最终结果满足业务规则，而不是等于某个固定字符串
• 边界层：空输入、超长输入、工具报错、工具超时，这些都要有用例
• 回归层：每次修改提示词或工具描述后全量跑一遍，看通过率有没有掉
• 统计口径：通过率要记录，单次通过不代表稳定，趋势才说明问题

概率性系统做不到零波动，验收要定的是「多少次里对多少次」。这个阈值必须产品和技术一起拍，不能研发单方面定一个自己够得着的数。定阈值的时候顺带想清楚：低于阈值是回滚还是转人工，这条规则上线前就要有。

成本和延迟：请求数不再等于用户操作数

传统软件里，用户点一下基本对应一次请求，成本和延迟大致是加法。Agent 不一样，用户点一下，内部可能跑好几轮模型调用加工具调用，成本和延迟都是乘法关系。用户看到的是一次操作，账单上可能是七八次调用。

上线前至少要摸底两个数：单次任务的平均轮次，以及 P95 延迟。平均值好看不代表体验好，尾部延迟才是用户投诉的来源。这两个数不需要精确到小数，但要有个量级判断，不然等账单来了才发现就晚了。

平均轮次

单次任务平均跑几轮模型调用，决定成本的基本盘

P95 延迟

百分之九十五的任务在多少时间内完成，决定用户体感

工具空窗期

工具执行期间没有流式输出，首字慢和断流更容易出现在这里

成本熔断

单次任务或单用户超过预算时强制中断，护栏的一部分

流式体验在 Agent 场景里更棘手，因为中间夹着工具执行的空窗期，用户会感觉卡住了。工程上要么在工具执行时给进度提示，要么把可并行的读取提前，这些细节做不做，体感差别很大。

线上运维：失败模式换了一套

传统服务的故障大多是挂了、超时、返回错，监控盯的是可用性和错误率。Agent 会多出一种「跑得挺顺但结果错的」——接口都成功，流程走完了，结果就是不对。这种故障在传统指标里完全看不见，监控得补上结果质量这一维。

护栏不是可选项，是上线前置条件。步数上限防止无限循环，工具白名单防止越权，成本熔断防止账单失控。这三样缺一个，都不该让它面向真实用户跑。

日志要能复盘一轮完整的决策链：每一步的输入是什么、选了哪个工具、返回了什么、下一步为什么这么走。缺一环就没法查。传统日志按请求存，Agent 的日志得按「一次任务」存，把整条链串起来。

什么情况下别用 Agent

不是所有东西都值得套 Agent。流程固定且分支有限、对延迟极敏感、结果必须可复现、出错代价极高的场景，传统实现更稳也更便宜。这类场景硬上 Agent，得到的是一个更贵、更慢、更难测的版本，没有任何收益。

有个简单的判断方法：如果这件事的判定标准你现在都写不清楚，那就不适合交给 Agent。你自己都说不清什么叫「做得好」，模型更不可能稳定地做到。先把标准写清楚，再谈要不要让它自主执行。

折中做法是先做「人在环中」的半自动版本，模型只出建议，由人确认后再执行。跑一段时间攒了数据，知道它在哪些情况下靠谱、哪些情况下容易错，再谈放权。这个路径慢一点，但比直接放权然后出事故返工要快。想对照各家模型在不同任务上的表现，可以到站内的模型资料库看当时的评测数据，别凭印象选。