别被模型宣传骗了，真实 Agent 任务一跑就知道

1. 引言

打开任何一家大模型厂商的官网，你都会看到“智能体（Agent）”、“自主决策”、“任务规划”等炫酷词汇。Demo 视频里，AI 仿佛无所不能：自动订餐、写代码、管理日程，一气呵成。但当你真正把模型接入自己的业务系统，跑一个真实的 Agent 任务时，往往会发现理想与现实的巨大鸿沟。

本文不讨论理论，只讲实战。我们将通过一个典型的“信息检索与报告生成”任务，看看当前主流模型在真实 Agent 场景下的表现，以及那些宣传片里不会告诉你的坑。

2. 任务设定：一个“简单”的 Agent 任务

我们设计一个看似简单的任务，它涵盖了 Agent 的核心能力：工具调用、信息整合、长文本生成。

• 任务目标：根据用户提供的“公司名称”，自动完成以下步骤：
  1. 搜索：使用搜索引擎 API 查找该公司最近一个月的三条重要新闻。
  2. 分析：调用一个“情感分析”工具，判断每条新闻的情感倾向（正面/负面/中性）。
  3. 生成报告：将搜索结果和分析结果整合，生成一份 300 字左右的“公司舆情简报”。

这个任务没有复杂的逻辑，只有三个明确的步骤。理论上，任何支持 Function Calling 的模型都能轻松完成。

3. 真实跑分：那些宣传片不会告诉你的“翻车”现场

我们分别用模型 A（某顶级闭源模型）和模型 B（某顶级开源模型）来跑这个任务，每个模型跑 10 次，记录成功率。

3.1 翻车点一：工具调用“幻觉”

这是最致命的问题。模型在调用工具时，会凭空捏造参数。

• 案例：在调用“搜索”工具时，模型 A 有 3 次没有使用用户提供的“公司名称”，而是自己“创造”了一个相似但不存在的公司名去搜索。模型 B 更夸张，有 5 次直接跳过了搜索步骤，声称“已根据内部知识库完成分析”。
• 宣传 vs 现实：宣传片里，模型总是精准调用 API。现实中，模型会“忘记”传参、传错参，甚至“发明”一个不存在的 API 来调用。

3.2 翻车点二：任务规划“短路”

Agent 的核心是“规划”，但模型经常在规划中“抄近路”或“迷路”。

• 案例：任务要求“先搜索，再分析，最后生成报告”。模型 A 有 2 次在搜索后，直接生成了报告，跳过了“情感分析”步骤。模型 B 有 1 次在分析完第一条新闻后，就认为任务完成，直接输出了不完整的报告。
• 宣传 vs 现实：宣传片里，模型会画出完美的思维导图。现实中，模型会“偷懒”，忽略中间步骤，导致结果不完整。

3.3 翻车点三：上下文“失忆”

Agent 任务通常需要多轮交互，模型在处理长上下文时，会“忘记”之前的指令或结果。

• 案例：在生成报告阶段，模型 A 有 1 次完全忘记了“情感分析”的结果，在报告中写“根据情感分析，该新闻为中性”，但实际分析结果是“负面”。模型 B 有 2 次在报告开头引用了第一条新闻，但写到后面，把新闻 A 的内容和新闻 B 的内容混淆了。
• 宣传 vs 现实：宣传片里，模型能处理百万 token 的上下文。现实中，在几十轮工具调用后，模型就开始“断片”，逻辑混乱。

4. 数据说话：10 次任务的成功率

结论：即使是当前最强的模型，在这样一个简单的 3 步 Agent 任务中，完全成功率也远未达到 100%。宣传片里 100% 的成功率，是在精心设计的、无干扰的、单次运行的 Demo 中取得的。

5. 如何让 Agent 更“靠谱”？

既然模型本身不可靠，我们就要从工程层面进行兜底。以下是一些实战经验：

1. 强制规划：不要完全依赖模型的自主规划。使用ReAct或Plan-and-Execute等框架，将任务步骤在 Prompt 中写死，并让模型每一步都输出“当前步骤”和“下一步计划”，便于追踪和纠错。

   下面是一个简单的步骤追踪伪代码示例，展示如何用状态机强制 Agent 按顺序执行：

   importjson# 定义任务步骤STEPS=["search_news","analyze_sentiment","generate_report"]defrun_agent_with_forced_plan(user_input:str):"""强制按步骤执行，每一步都校验模型输出"""context={"company":user_input,"news":[],"sentiments":[]}forstepinSTEPS:print(f"[当前步骤]{step}")# 将当前步骤和已完成状态注入 promptprompt=build_prompt(context,current_step=step,completed_steps=STEPS[:STEPS.index(step)])response=llm_call(prompt)# 调用大模型# 解析模型输出，要求它必须返回当前步骤的结果result=parse_step_output(response,step)ifresultisNone:print(f"[错误] 步骤{step}输出格式异常，重试或终止")returnNone# 更新上下文context.update(result)print(f"[完成]{step}->{result}")returncontext["report"]

2. 结果校验：对每个工具调用的返回结果进行校验。例如，检查搜索 API 是否返回了有效结果，情感分析 API 是否返回了预期的 JSON 格式。如果校验失败，让模型重试或报错。

   以下是一个 API 返回校验的代码片段，确保工具调用结果符合预期：

   defvalidate_search_result(result:dict)->bool:"""校验搜索 API 返回结果是否有效"""required_fields=["title","url","snippet"]ifnotisinstance(result,dict):print("[校验失败] 返回结果不是字典")returnFalseif"items"notinresultorlen(result["items"])==0:print("[校验失败] 搜索未返回任何结果")returnFalseforiteminresult["items"]:forfieldinrequired_fields:iffieldnotinitem:print(f"[校验失败] 结果项缺少字段:{field}")returnFalsereturnTruedefvalidate_sentiment_result(result:dict)->bool:"""校验情感分析 API 返回格式"""expected_format={"label":str,"score":float}ifnotisinstance(result,dict):returnFalseforkey,val_typeinexpected_format.items():ifkeynotinresultornotisinstance(result[key],val_type):print(f"[校验失败] 情感分析结果缺少或类型错误:{key}")returnFalseifresult["label"]notin("positive","negative","neutral"):print(f"[校验失败] 情感标签值非法:{result['label']}")returnFalsereturnTrue# 使用示例search_result=call_search_api("某公司")ifnotvalidate_search_result(search_result):retry_or_fallback(search_result)# 重试或降级

3. 状态管理：将 Agent 的“状态”（已完成步骤、已获取数据）显式地记录在上下文中，而不是让模型自己记忆。例如，在每次工具调用后，都更新一个“任务状态”变量。

4. 降级策略：为每个步骤设计降级方案。如果模型无法调用搜索 API，可以退而求其次，让它基于已有知识生成一个“免责声明”式的报告，而不是直接崩溃。

6. 总结

大模型的 Agent 能力确实在飞速进步，但距离“可靠”还有很长的路要走。厂商的宣传片展示的是“上限”，而真实业务需要的是“下限”。下次再看到令人心动的 Agent Demo 时，不妨问自己一句：“这个任务，跑 100 次，能成功几次？”

只有亲自跑一遍，你才会知道，那些光鲜亮丽的宣传背后，藏着多少需要工程师去填的坑。