Agent产品实践：从工具调用到任务编排的进化

2025 年大家都在聊 Agent，但大部分"Agent 产品"只是带工具调用的 Chatbot。

我们的数据分析 Agent 迭代了五个月，从 v0.3 的"能查数"进化到 v2.0 的"能办事"。这篇文章记录 Agent 产品化的关键进化节点，以及每个节点我们踩的坑。

先定义：什么才算 Agent

我的判断标准很简单——自主性与闭环性：

• Chatbot：用户说一步，它动一步
• 工具调用 Chatbot：能查天气的 Chatbot，还是说一步动一步
• Agent：给它一个目标（"分析上周华东区销售下滑原因"），它自己拆解任务、调用工具、迭代执行、交付结果

v0.3：ReAct 循环 + 三个工具

最初的架构是最经典的 ReAct：思考 → 行动 → 观察 → 再思考。工具只有三个：查数据库、画图表、读文档。

两周就跑通了，Demo 很唬人。然后问题来了：

坑一：死循环。 Agent 查不到数据会换个问法再查，无限重试烧 token。解法是给循环加硬约束：最大步数、最大 token、重复动作检测（连续两次相同工具调用即中断）。

坑二：错误的中间结论自我强化。 第一步算错了一个汇总值，后面所有推理都建立在错误地基上。解法是关键中间结果做"自我校验"——让 Agent 用另一种查询路径交叉验证关键数字。

v1.0：规划与记忆

v0.3 的 Agent 像无头苍蝇，问题出在缺少规划。v1.0 引入两层结构：

Planner（规划器）：把目标拆成任务 DAG，明确每步的产出物
Executor（执行器）：逐个执行任务，失败可单任务重试
Reflector（反思器）：阶段性地检查中间产出，决定继续/修正/终止

同时加了记忆系统：短期记忆（当前任务的上下文）+ 长期记忆（用户偏好、历史任务结论，向量检索召回）。有了记忆，Agent 开始"认识"用户——知道 CFO 喜欢看同比而不是环比，知道某个指标的口径陷阱。

v2.0：从单兵作战到任务编排

真正的转折点是发现用户要的不是"一次问答"，而是"周期性的事务"：每周一自动生成经营周报，异常波动自动归因并推送。v2.0 的 Agent 变成了被编排的服务：

• 触发器（定时/事件/人）启动任务
• 任务模板 + 参数化的 Planner
• 执行过程全链路可观测，人类可随时介入
• 交付物沉淀到知识库，成为下一轮任务的输入

Agent 产品的三道坎

坎一：可靠性天花板

单步工具调用准确率 95%，十步链条的端到端成功率只有 59%（0.95^10 ≈ 0.599）。我们的应对：

• 缩短链条：能并行就并行，能合并就合并
• 关键节点设检查点，失败只回滚到检查点而不是从头再来
• 兜底策略：复杂任务自动降级为"生成分析计划 + 人确认 + 分步执行"

坎二：权限与安全

让 Agent 拿着数据库权限自主写 SQL，安全事故只是时间问题。我们做了权限分级（只读/受限写/需审批）、SQL 执行前的静态校验、生产环境全量审计日志。给 Agent 的每个权限，都要假设它会被提示词注入攻击者滥用。

坎三：信任建立

用户不信任 Agent 的输出，就不会用。三个有效手段：每个结论附完整证据链（查了什么、算了什么）；执行过程实时可视化（像看外卖配送进度一样看 Agent 干活）；置信度显式表达，低置信主动说"我不确定"。

结语

Agent 的产品化，技术只占 40%，剩下 60% 是在不可靠性之上构建可靠的工程护栏和信任机制。模型能力每半年上一个台阶，但护栏和信任的设计，值得从第一天就认真做。