Agent 从任务到结果，中间到底发生了什么？3 个真实实例拆解每一轮循环

摘要：现在网上讲 Agent，很多文章还停在“它是什么”和“演示里它有多强”。真到自己上手，卡住人的通常不是概念，而是过程：任务扔进去之后，它中间到底跑了几轮？每一轮在判断什么？遇到没预设过的情况，它会不会自己改路，还是直接跑偏？这篇文章不再重复定义，直接拆 3 个真实场景的完整运行过程：电商客服、数据分析、信息研究。你会看到一个 Agent 怎么进入循环、怎么试错、怎么翻车，又是怎么被阈值、人工审核和流程设计兜住的。

文章标签：#Agent #智能体 #ReAct #LLM应用 #AI落地

先看结论

如果你赶时间，先记住 4 句话：

• Agent 不是“一句话进去，一个答案出来”，而是一轮轮 判断 -> 动作 -> 观察 的循环。
• 它最强的地方，是能根据运行时信息临时改路线。
• 它最脆的地方，是每一轮都可能判断错、调用错，或者把上下文带丢。
• 真正能落地的架构，不是全自动，而是 Agent 跑流程，人类守节点。

目录

• 为什么看完演示还是不会做 Agent
• 先看 3 个实例到底在回答什么
• 问题 1：Agent 从收到任务到输出结果，中间到底跑几轮
• 问题 2：Agent 自主决策时，到底在判断什么
• 问题 3：Agent 遇到没预设过的情况，真的能自己调整路线吗
• 怎么判断你的场景该不该上 Agent
• 结论：让 Agent 跑流程，让人类守节点

为什么看完演示还是不会做 Agent

很多开发者都遇到过这一幕。

你看到一个 Agent 演示：一句话下去，它自己调接口、拉数据、做分析、写报告，全程丝滑。你照着接工具、配提示词、补工作流，心里想，这事大概也就这样了。

结果真正一跑，第一步就查错表，第二步传错参数，第三轮开始忘目标，最后还给你写出一段看着挺像那么回事、其实和任务没什么关系的“正确废话”。

这时候你很容易往两个方向怀疑：是不是自己提示词没写好，或者模型还不够强？

多数时候都不是。更常见的差距在于，演示只展示了一次成功路径，真实业务面对的却是每天成百上千次调用。WebArena 基准测试里，优秀 Agent 在网页任务上的成功率也只有约 57.1%。CSDN

说白了，演示展示的是一条最顺的成功路径，工程面对的是所有会偏航的真实路径。

你可以把 Agent 想成一个边走边看路的实习生。

• 优点是灵活，前面没写死的岔路，它也敢选。
• 缺点是它不是每次都选对，而且走远了还可能忘记自己最初要去哪。

所以真正值得搞懂的，不是“Agent 能不能做事”，而是下面这些更实在的问题：

• 它从收到任务到输出结果，中间到底跑几轮？
• 每一轮里，LLM 在判断什么、调用什么、可能错在哪？
• 遇到没预设过的情况，它真能自己换路线吗？
• 出错之后，到底靠什么兜底？

下面这 3 个实例，就按这四个问题一个个拆。

先看 3 个实例到底在回答什么

先把全局扫一眼，再进细节，会更容易看明白。

实例	典型轮次	主要判断	最容易翻车的地方	常见兜底
电商客服	2~3 轮	识别用户意图、锁定订单、判断是否催单或转人工	订单识别错、多轮上下文漂移	置信度阈值、转人工
数据分析	4~5 轮	识别文档结构、抽取表格、处理附注、计算同比	跨页表头断裂、附注漏读、格式异常	人工复核输出
信息研究	5~8 轮	决定搜什么、是否继续搜、哪些信息足够写摘要	旧闻当新讯、来源不可靠、过早收手	人工核验来源

这 3 个例子的复杂度是逐级上升的。

• 电商客服最适合看“Agent 到底跑几轮”，因为动作空间很小，循环最短。
• 数据分析最适合看“它到底在判断什么”，因为每一步都牵涉结构识别和异常处理。
• 信息研究最适合看“它能不能自己改路线”，因为下一轮搜什么，完全取决于上一轮搜到了什么。

问题 1：Agent 从收到任务到输出结果，中间到底跑几轮

很多人第一次接触 Agent，脑子里默认的画面都是“输入一句话，系统给答案”。

真实运行方式更像 ReAct 循环：先判断现在发生了什么，再决定做一步动作，接着观察工具返回，最后决定要不要进入下一轮。

电商客服是最适合看清这个循环的例子，因为动作空间很小，通常就四类：查物流、催单、退款、转人工。

任务输入

用户在客服对话框输入：

我上周买的那个东西，快递三天了还没到，到底怎么回事？

第一轮：感知意图，锁定对象，选择工具

Agent 拿到的上下文大致像这样：

用户消息：我上周买的那个东西，快递三天了还没到
用户账号：user_12345
最近 3 笔订单：
- 订单 A：3 天前下单，已发货，物流单号 SF1234
- 订单 B：12 天前下单，已完成
- 订单 C：20 天前下单，已完成
可用工具：[query_logistics, submit_urgent, process_refund, transfer_to_human]

这一轮里，LLM 真正在做的不是“回答用户”，而是先判断三件事：

• 用户在问什么，核心意图是查物流还是催单。
• 用户指的是哪一笔订单。
• 现在哪个工具最合适。

它大概率会推理成：

用户说“三天没到”，最可能是订单 A。当前意图是查物流，应该先调用 query_logistics。

于是它做出决策：

query_logistics(order_id="A", tracking="SF1234")

这里最容易翻车的点，是自然语言描述和真实订单并不总能对上。用户说“上周买的”，但实际可能指的是 12 天前那单。Agent 抓住了“三天没到”这个线索，所以大多数情况下会选订单 A，但一旦用户自己记错时间，第一轮就会查偏。

第二轮：观察结果，决定回复策略

工具返回：

物流状态：到达派送网点，待派送
预计派送：今天下午

这时 LLM 的工作不是机械复述，而是判断“这个结果意味着什么”。

它会把信息压缩成一句内部判断：

不是滞留，只是还没派送；可以先告诉用户预计今天下午送达，并补一句是否需要催单。

于是系统回复：

快递已到派送网点，预计今天下午派送。需要我帮你催一下吗？

用户接着说：

催一下，多久能到？

第三轮：保持上下文，完成动作

这一轮最难的，不是“催单”本身，而是上下文别丢。Agent 需要同时记住：

• 当前聊的是订单 A。
• 物流已经到派送网点。
• 用户现在要的是催单，不是重新查物流。

所以它的推理会变成：

用户要催单，继续处理订单 A；当前状态已到网点，催单后通常今天内送达。

然后做出动作：

submit_urgent(order_id="A")

最后给出回复：

已帮你催单，通常今天内会送达；如果晚上还没收到，我可以继续帮你转人工跟进。

如果这中间插入一段无关对话，比如用户先问一句“周末会派送吗”，上下文一长，Agent 的注意力就可能偏掉，第三轮回头忘了自己还没执行催单。这就是为什么很多客服 Agent 一开始看起来聪明，聊久了却像短时记忆断片。

先落个小结

放在客服场景里看，一个典型 Agent 从收到消息到给出可执行结果，通常也就跑 2~3 轮。

但轮次短，不等于这事就轻松。它每一轮都踩在两类高风险判断上：

• 第一类是意图和对象有没有识别对。
• 第二类是上下文有没有一直稳稳地带到最后。

真实系统里，很多团队还会额外加一个置信度阈值。低于阈值，比如低于 0.7，系统就不硬答，直接转人工；涉及退款这类有财务风险的动作，阈值通常还会再往上提。哪怕模型看起来很有把握，也往往只让它生成建议，不让它直接执行。CSDN

问题 2：Agent 自主决策时，到底在判断什么

客服场景里，Agent 的判断已经不少，但还比较容易看懂，因为动作少、反馈快。

数据分析场景就不一样了。这里的“自主决策”不再只是“调哪个工具”，而是要不断判断哪些内容算数据、哪些算注释、哪些异常必须保留、哪些结构需要重新拼起来。

任务输入

用户上传一份 20 页 PDF 财报：

帮我把里面的财务数据整理成表格，标出同比下滑超过 10% 的项。

第一轮：读 PDF，但先判断哪里值得读

Agent 调用 PDF 解析工具后，拿到的是整份文档的文本和版面信息。

问题来了：拿到文本，不代表已经拿到“表格”。

这时 LLM 要先判断：

• 哪几页是正文说明，哪几页是财务表格。
• 表格是不是跨页。
• 哪些附注虽然不在表格里，但会影响后面的计算。

它可能做出的内部判断是：

前 3 页偏公司概况；第 4 到第 18 页是财务报表主体；第 19 到第 20 页是附注，需要保留索引关系。

如果利润表刚好从第 5 页跨到第 6 页，而分页符把表头和第一行数据拆开，Agent 就可能误把第二页第一行当新表头。这种错不是数学错，而是结构错，后面再怎么算都很难救。

第二轮：抽取数字，但别把注释抽掉

很多 PDF 单元格并不干净，会长这样：

营业收入：1,250 万（含税）
营业成本：890 万
注：本季度营业收入含一次性政府补助 50 万

这一轮里，LLM 要决定的事情比想象中多：

• 1,250 万 是不是保留成数值字段。
• 含税 算噪音还是算备注。
• “一次性政府补助 50 万”是扔掉，还是单独保留，供后面解释同比使用。

比较靠谱的做法不是只取数字，而是拆成两层：

• 数据层：保留 1,250 万。
• 解释层：保留“含税”“一次性政府补助 50 万”。

因为对读者真正有价值的，往往不是“算出了 -10.7%”，而是“这个 -10.7% 其实还被一次性补助美化过”。

这里最容易翻车的地方，就是附注和表格不在同一页。如果附注在第 18 页，而收入表在第 5 页，Agent 很可能先抽到数字，来不及建立跨页关联，最后给你一个形式上整齐、语义上有坑的表。

第三轮：开始计算，但先判断怎么算才公平

整理完字段后，Agent 才会进入计算：

项目       | 本季度   | 去年同期 | 同比变化
营业收入   | 1,250 万 | 1,400 万 | -10.7%  ⚠
营业成本   | 890 万   | 920 万   | -3.3%
毛利润     | 360 万   | 480 万   | -25.0% ⚠

如果它还记得前面的附注，就会继续推一步：

本季度收入包含一次性政府补助 50 万；如果剔除，营业收入实际约为 1,200 万，同比下滑约 14.3%。

看到这里，Agent 的“自主决策”其实就能拆开看了。它不是玄学，核心就是三件事：

• 识别结构：哪些字段是数据，哪些只是说明。
• 处理异常：括号、附注、跨页信息该怎么保留。
• 决定动作：现在继续抽取，还是可以进入计算与总结。

第四轮：生成摘要，把异常说人话

最后输出可能长这样：

【异常项标注】
1. 营业收入：1,250 万，同比下滑 10.7%
   备注：含税；含一次性政府补助 50 万，剔除后实际下滑约 14.3%
2. 毛利润：360 万，同比下滑 25.0%

看到这里你就会发现，Agent 每一轮所谓的“自主决策”，本质上就是在做运行时判断。它不是提前写好了“遇到括号怎么办”“遇到一次性补助怎么办”的 if-else，而是根据当前文档内容，现场给出一个尽量说得过去的处理。

问题也恰恰出在这里：说得过去，不等于一定正确。

所以这类任务真要落地，最稳的做法通常不是全自动，而是“Agent 先整理，人工再复核”。这类错误大多还能补救，改数字、改备注、补附注都来得及，所以它反而是很适合上 Agent 的场景。

问题 3：Agent 遇到没预设过的情况，真的能自己调整路线吗

前两个例子里，路径虽然会翻车，但大方向还是相对稳定的。

• 客服大体就是查、催、退、转。
• 数据分析大体就是读、抽、算、写。

信息研究场景不一样。它最有价值的地方，恰恰在于下一步搜什么，往往没法提前写死。每一轮搜索方向，都是上一轮结果逼出来的。

任务输入

用户给出一个很宽的任务：

调查一下 XX 公司的供应链风险，写一份摘要。

第一轮：先拆问题，再决定第一跳搜什么

如果直接搜“XX 公司 供应链风险”，大概率会出来一堆泛泛的新闻稿和营销文。

所以 Agent 通常会先做一层问题分解：

• 供应链风险和谁最相关。
• 关键供应商是谁。
• 供应商位于哪里。
• 当地最近有没有影响供货的事件。

于是第一轮搜索更可能是：

XX 公司 供应商 供应链

搜索结果里如果出现“核心供应商为 YY 科技，位于东南亚 Z 国”，第二轮的方向就立刻变了。

第二轮：根据结果改路线，不是按脚本往下走

现在 Agent 的内部推理会变成：

既然核心供应商在 Z 国，那下一步应该查 Z 国最近有没有影响物流、生产或出口的事件。

于是它搜索：

Z 国 2026 港口 罢工 供应链 风险

这一步已经体现出 Agent 和传统程序最像样的区别了：它不是在执行一条预先排好的搜索脚本，而是在根据刚得到的新信息改路线。

但这一步也很容易中招。比如它查到一篇“Z 国港口工人罢工已持续两周”的报道，看起来很合理，实际上可能是 3 个月前的旧闻。LLM 很擅长把“像真的”拼起来，却不天然擅长判断信息有没有过期。博客园

第三轮：继续追问，把风险链条补完整

如果第二轮发现“Z 国有港口罢工”，下一轮很自然会继续追：

YY 科技 Z 国 出口港 物流 影响

假设结果显示：YY 科技主要出口港是 W 港，而 W 港正处在罢工影响范围内，预计延误 3~4 周。

这时 Agent 就把原本很抽象的“供应链风险”，一步步压实成了具体链条：

• XX 公司依赖 YY 科技。
• YY 科技位于 Z 国。
• Z 国港口近期罢工。
• YY 科技主要出口港 W 港正受影响。
• 所以 XX 公司短期供货存在延误风险。

第四轮：自己判断“信息够了没有”

研究类 Agent 最难的一步，常常不是搜索，而是停手。

搜太少，结论会飘；搜太多，成本会上去，上下文还可能被稀释掉。

所以它需要在某一轮做一个主观判断：

核心供应商、地理位置、风险事件、影响链条都已补齐，可以停止搜索，进入综合摘要。

这个“够了”的判断，没有硬标准。它完全依赖模型当场对信息完整度的感觉。也正因为如此，研究 Agent 经常会出现两种相反的问题：

• 过早收手，漏掉关键来源。
• 过度搜索，越搜越散，最后把上下文冲淡。

第五轮：生成摘要，但别把它当终稿

最后它可能输出：

【XX 公司供应链风险评估】
核心供应商 YY 科技位于 Z 国，其主要出口港 W 港近期受罢工影响，预计出货延误 3~4 周。
风险等级：中高。
建议：持续跟踪罢工进展，关注公司财报中的供应链说明，并预评估替代供应商。
注意：结论基于公开信息整理，关键来源仍建议人工核验后再使用。

这里也落个小结

Agent 确实能在没预设过的情况下调整路线，但会调整，不等于调整得对。

它最强的地方，是能把“先试一步，再看结果，再换方向”这件事做出来；它最脆的地方，是对来源时效性、证据强弱和信息完整度的判断一直不算稳。

所以研究型 Agent 更合适的位置，不是“自动写结论”，而是“自动跑信息收集和初稿整理”。最后那一下拍板，还是得交还给人。

怎么判断你的场景该不该上 Agent

看完上面 3 个例子，判断逻辑基本可以压到 5 个维度里。

维度	更适合用 Agent	不太适合用 Agent
决策空间	大，没法枚举完	小，几条规则能写清
动作空间	有边界，工具集合可控	完全开放，随时可能做出高风险动作
错误后果	可恢复，错了能改	不可逆，错一次代价极高
延迟容忍	秒级可接受	必须毫秒级响应
频率与成本	低频高价值	高频低价值

把这 5 个维度套回 3 个场景：

• 电商客服：动作有限，错误大多可恢复，但涉及退款等高风险操作时必须加人工审批。
• 数据分析：决策复杂，动作有限，错误可复核，所以很适合做“Agent 预处理 + 人工终审”。
• 信息研究：最能体现 Agent 的灵活性，但也最依赖来源核验和成本控制。

如果你还是拿不准，可以先用下面这条最短判断链：

这张图想说的就一句话：别先问“能不能做 Agent”，先问“值不值得把一部分决策权交给 Agent”。

结论：让 Agent 跑流程，让人类守节点

3 个例子看完，规律很一致：没有哪个靠谱的 Agent 系统，会从头到尾完全放手让它自己跑。

实例	Agent 自主完成比例	人工介入环节	为什么要介入
电商客服	约 65%	高风险操作审批、低置信度转人工	财务和服务风险高
数据分析	约 90%	输出复核	一个数字错，后面都跟着错
信息研究	约 80%	关键来源核验	搜索结果可能过时或失真

这也是很多团队最后会收敛到的架构：

• Agent 负责跑流程，承担“试一步、看结果、先整理”的工作。
• 人类负责守节点，在高风险动作、低置信度结果和关键结论处做终审。

这不是保守，就是工程理性。

无容错 Agent 系统的平均可用性约 75%，离工业级系统常说的 99.9% 还差很远。WebArena 上 57.1% 的成功率，也远没到“可以放心托管一切”的程度。CSDN

站在这个现实上看，“Agent 跑流程 + 人类守节点”不是权宜之计，而是现阶段最靠谱的落地方式。

下次再有人说“Agent 可以自主完成一切”，你可以只追问一句：

它每 100 次里，稳定成功多少次？

如果这个数字还停在 57 左右，你的系统设计就别假装它是 100。

如果你正在做 Agent 项目，这篇文章最值得带走的，可能不是某个术语，而是一种设计习惯：

• 把每一轮都当成可能出错的一轮来设计。
• 把每一个高风险动作都当成必须兜底的动作来设计。
• 把 Agent 当成会跑流程的系统，而不是一个可以自动负责到底的系统。

参考资料

1. LLM Agent 落地短板：斯坦福虚拟小镇实验数据
2. LangGraph 错误处理与 Agent 可用性数据
3. 为什么 LLM 搞不定复杂任务：认知局限分析
4. 从填空到形式化：LLM Agent 的工程边界与设计范式
5. Human-in-the-Loop 在 Agent 中的实践

版权声明：本文为原创整理，引用数据均来自公开资料，仅作学习与交流使用。

如果这篇文章帮你把 Agent 的运行过程看清了一点，欢迎点赞、收藏，也欢迎关注我的专栏。后面我会继续拆 Agent 开发、工作流设计、提示词和 AI 落地里的真实工程问题。