很多人第一次接触 Agent，会下意识拿它当普通软件用：以为点一下按钮就该有固定结果，结果同一句话问两遍给出的东西都不一样，于是怀疑是不是工具坏了。这篇不聊协议也不聊框架，只把两者的差别摊开对照，帮你在设计流程、估成本、排错时先判断清楚自己面对的到底是哪一种东西。
很多人第一次接触 Agent，会下意识拿它当普通软件用：以为点一下按钮就该有固定结果，结果同一句话问两遍给出的东西都不一样，于是怀疑是不是工具坏了。其实这不是工具坏了，是你面对的根本不是同一类东西。普通软件像一台自动售货机，投币、按键、掉货，路径完全写死；Agent 更像你请来的一个临时助手，你说个目标，它自己琢磨怎么做，中间可能绕路也可能换方法。
这篇不聊协议也不聊框架，只把两者的差别摊开对照，帮你在设计流程、估成本、排错这三件事上先判断清楚：手上这个任务，到底该交给普通软件，还是交给 Agent。判断错了，要么白花不确定性成本，要么把一个明明需要临场判断的活硬写成死流程，最后天天打补丁。
输入和输出：确定的按钮 vs 会变的自然语言
普通软件的输入是有限选项，你点「导出 CSV」，它不会给你导出一份 PDF；输出也是可预期的，同样的输入跑十遍结果一样。Agent 的输入是一句人话，比如「把这几份合同里的关键条款整理成表」，输出是模型现场算出来的，同一句问两次，措辞、顺序、甚至漏掉哪一条都可能不同。
| 对比项 | 普通软件 | AI Agent |
|---|---|---|
| 输入形式 | 固定的按钮、下拉、参数 | 自然语言描述的目标 |
| 输出稳定性 | 同一输入结果一致 | 同一输入结果可能变化 |
| 测试方式 | 写死预期结果逐字比对 | 写范围断言，如必须含某字段 |
| 出错定位 | 能定位到具体函数或行 | 往往要复盘某一轮判断 |
所以给 Agent 写测试，别指望逐字比对。正确做法是写范围断言：要求返回里必须包含某个字段、必须能解析成 JSON、必须落在允许的取值集合里。什么情况下不适用这条？如果你把 Agent 的输出限制得很死，比如只允许它调用一个函数、返回一个状态码，那它这时候的表现就非常接近普通软件，随机性不再是问题，按普通软件测就行。
谁来定流程：代码写死 vs 模型临场决定
普通软件的步骤顺序是开发者写死的，第一步校验、第二步请求、第三步落库，一目了然。Agent 是模型看着任务自己决定：先查资料还是先调接口，要不要再确认一次，一共跑几轮，都不固定。这带来一个直接后果：你没法从代码里一眼看出它总共会跑多久、花多少钱，只能靠上限约束——最多几步、最多几次工具调用。
- 给步数封顶明确这个任务最多允许它跑几轮，比如超过就强制返回当前结果并提示人工接管，别让它无限试。
- 给工具列白名单只开放这个任务真正需要的工具，避免它自己找来一堆无关接口反复调用。
- 记中间过程每一轮的输入、输出、耗时、调用了什么工具都落盘，出问题时你能顺着时间线复盘是哪一轮跑偏。
- 复盘时看那一轮普通软件报错能定位到某一行，Agent 出问题往往是某一轮判断跑偏，把那一轮的上下文调出来比读代码有用。
什么情况下不适用 Agent？流程固定、规则明确的活，比如每天定时把固定格式的文件搬到另一个目录，用普通代码或固定工作流更省事、更稳，硬塞进 Agent 只会增加不确定性和成本。判断标准就一句：这一步能不能提前写清楚？能，就别交给模型临场决定。
边界与成本：跑一次多少钱不好预估
普通软件跑一次成本基本恒定，服务器按时间计费，跟输入内容无关。Agent 每轮都要把上下文重新喂给模型，步数越多、上下文越长，成本越高，这是结构性差异，不是实现得不好。所以上线前必须设三道闸：步数上限、单次任务的花费上限、工具白名单，避免它陷进「调一次错一次再调一次」的循环。
- 步数上限：超过就停，返回当前结果并标记需要人工看
- 花费上限：单次任务累计到阈值就中断，不让它继续烧
- 工具白名单：只给这个任务必要的工具，减少无意义调用
- 超限处理：想清楚超限后是直接失败，还是降级返回半成品
- 日志留痕：每轮的用量记下来，方便事后核对是哪一段吃掉了预算
判断标准很简单：如果一个任务你觉得「它最多试三次就该给我答案」，那这个三次就是你要设的上限，而不是指望它自己收手。想横向看不同模型在这种多轮场景下的实际表现和当期口径，可以到 AI 测评榜单（/benchmarks） 翻一翻，别拿几个月前的旧印象下结论。
落地前的一张对照清单
入门阶段最容易犯的错，是任务还没想清楚就先挑框架。其实顺序应该反过来：先判断任务类型，再看容错能力，最后看能不能观测。三步都过了，才轮到选工具。下面这张清单可以当上线前的自检表。
| 自查问题 | 倾向普通软件/固定流程 | 倾向 Agent |
|---|---|---|
| 每一步能提前写清楚吗 | 能 | 不能，需要看情况决定下一步 |
| 结果错了能人工复核吗 | 不能接受复核 | 能接受复核再修正 |
| 能记录每轮输入输出吗 | 不需要 | 必须能，否则没法排错 |
| 任务重复度高吗 | 高，固定套路 | 低，每次情况不同 |
先问任务类型：如果每一步都能预先写清楚，用普通软件或固定工作流；如果中间需要看情况决定下一步，才考虑 Agent。再问容错：结果错了能不能接受人工复核一遍，能就走 Agent，不能就先别上。最后问观测：能不能把每一轮的输入、输出、耗时、花费记下来，记不下来就等于上线后没法排错。
还有一条容易被忽略：别把 Agent 当成能自我兜底的黑盒。它不会因为你没设上限就自动收敛，也不会因为你没记日志就帮你还原过程。这些边界得你来划。想看看实际跑起来大概什么量级、别人怎么估的，可以去 真实用量榜（/usage） 和 模型成本计算器（/tools/model-cost-calculator） 按你实际会跑的次数估一遍。
下一步先拿你手上最想自动化的那个任务，按上面清单过一遍：能提前写清楚就写代码，需要临场判断再上 Agent，接着到站内用量与成本页面核对当时的数字，把上限设在预估之上一点点，别靠感觉。→常见问题
Agent 是不是就是多了个界面、能自动化的普通软件？
不是。普通软件的流程是开发者写死的，Agent 是模型在每一步看情况自己决定下一步做什么。前者结果是可预期的，后者是在一个范围内浮动，你要做的是给这个范围设边界，而不是指望它每次给你一模一样的结果。
那我是不是所有功能都该换成 Agent？
反了。判断标准是任务中间要不要临场判断：规则明确、步骤固定的活，普通代码跑得更快更便宜也更稳；只有需要「看情况决定下一步」的环节才值得交给 Agent，混着用比全换掉更实际。
怎么判断一个 Agent 做得对不对？
普通软件可以逐字比对输出，Agent 不行，得改成范围断言：结果必须包含哪些字段、必须调用过哪个工具、步数有没有超上限。想横向看不同模型在同类任务上的当期表现，到站内 /benchmarks 按当时的口径核对，别照搬别人几天前的结论。
