AI Agent和传统软件的区别

做需求时经常卡在一个问题上：这个功能到底该写成正常的软件流程，还是做成 Agent。选错了，轻则白花一笔调用费，重则上线后行为飘忽没人敢用。这篇不讲概念定义，只讲两者在运行逻辑上的差别，以及怎么用一张清单判断你手上的需求属于哪一类。

做需求评审时经常卡在同一个问题上：这个功能到底该按普通软件流程写，还是做成 Agent。选错方向的代价很具体——做成软件却硬塞模型，逻辑会变得又绕又难维护；做成 Agent 但需求其实很确定，上线后行为飘忽，工程师查不出原因，运营也不敢放手用。

这篇不讲概念定义，只讲两者在运行逻辑上的差别，以及怎么用一张清单判断你手上的需求属于哪一类。判断标准给的是口径，不是结论，具体落地时还要结合你的业务风险和你团队当下的工程能力。

执行路径：写死的分支 vs 现场决定

传统软件的执行路径是开发者预先枚举的。输入落到哪个分支、中间走几步、什么条件下退出，上线前就能画成一张流程图。Agent 的下一步靠模型当场判断，同一句输入换个说法，可能走出完全不同的路径，中间调用几次工具也不固定。

这直接带来两套不同的错误观。传统软件出错，多半是某个分支没覆盖到，或者边界值没处理，定位方式是看日志对分支。Agent 出错，往往是分支都走到了、工具也都调了，但决策本身不合理，比如该查库存的时候去改了订单。验收手段因此不一样：前者看用例覆盖，后者要看一批任务里有多少比例落在可接受范围。

• 判断口径：如果这个需求的所有分支你能在需求文档里穷举完，就先别上 Agent。
• 穷举不完，而且分支本身要靠语义理解才能选，才考虑 Agent 方案。
• 分支虽多但完全由规则和数值决定，比如对账、计价、税费计算，这种用传统代码更稳也更便宜。
• 如果需求里既有确定性环节又有理解环节，先拆开，别让整个流程都走模型。

状态放在哪：数据库 vs 上下文

传统软件的状态存在数据库和缓存里，进程重启状态还在，谁在哪一步一目了然。Agent 的「当前进展」很大程度上活在上下文窗口里，窗口一裁、会话一断，它就像失忆一样从头问起。产品经理最容易漏掉的就是这点：需求文档里写着「记住用户上次选的项目」，工程实现时却没有对应字段。

1. 关键状态显式落盘把任务 ID、当前步骤、已完成结论写进外部存储，每一步开始前先读回来，别指望模型自己记住。
2. 长流程拆成多步每个步骤结束把结论写下来，下一步只读结论，不背整段历史，比硬撑一个超长对话可靠得多。
3. 给会话设边界明确什么情况下开新会话、什么情况下续着跑，避免上下文无限膨胀。
4. 验证方式人为中断一次，看恢复后能不能接着走，恢复不了说明状态没真正落盘。

不过要提醒一句：一问一答、无后续动作的轻量场景，不必为了状态管理引入额外存储，那只会让链路更长、故障点更多。判断标准是「这个任务会不会跨多次交互、跨进程」，不会就不用加。

失败长什么样：抛异常 vs 跑偏

传统软件的失败通常是明确的报错和状态码，调用方一眼知道出了问题。Agent 的失败常常是「跑完了，但结果是错的」——不报错，日志干干净净，只是做了不该做的事，比如该问用户确认的时候自己下了单。

所以 Agent 需要补三类传统软件不常需要的护栏。这三项要在需求阶段就写进文档，别等上线出事再补。

工具边界

这个任务允许调用哪些接口，不允许碰哪些写操作，白名单形式写清楚

步数上限

最多走多少步、调多少次工具，超了就停下来交给人，防止无限循环

预算上限

单个任务最多花多少调用成本，超预算中止，避免一次异常拖垮整月额度

人工确认点

在不可逆动作之前插入确认，比如付款、删除、对外发送

验收口径也要跟着改：不看单次是否成功，而看一批任务里有多少比例落在可接受范围。具体阈值跟你的业务容忍度有关，可以到站内的评测页面核对当时的参考数字，别照搬别人的标准。

反过来，完全封闭、没有外部副作用的场景，比如纯文本生成、纯查询问答，护栏可以放宽，卡太死反而让体验变差。判断标准是：这一步做错了，会不会影响真实世界的钱、数据或用户。

一份需求归类自查清单

评审前拿下面四个问题过一遍，答案记在需求文档里，和工程口径对齐，能省掉后面很多返工。

• 四个问题里只有「理解语义」是「是」，多半做个带模型的普通功能就够，不必上 Agent 循环。
• 第一、三、四个都指向 Agent，才值得做成 Agent，并且要同步设计好上一条讲的三类护栏。
• 拿不准就先用小批量真实任务跑一轮，看人要多久兜底一次；频繁兜底说明该退回确定性流程。
• 合规或资金相关的高风险动作，即使前面条件都满足，也建议保留人工确认，不要全自动放行。
• 把结论写进需求文档，包括护栏参数和人工确认点，别只在会上口头说。