智能体编排：能用工作流解决的，别交给自主规划

「我们要做一个能自己思考、自己调工具、自己完成任务的智能体。」这是客户最常提的一句话，也是智能体项目翻车的起点。听起来最先进的自主规划，落地时往往不如一条把步骤写死的确定性工作流稳定、便宜、可解释。

鼎上娱乐做智能体编排的原则很简单：自主规划不是默认选项，而是最后手段。能用固定流程解决的，先别交给模型自由发挥。这篇讲清楚两者的边界，以及一旦要上自主规划，四个必须处理的工程问题。

先分清：确定性工作流 vs 自主规划

确定性工作流是「步骤已知」的编排：先识别意图，再查订单，命中就按模板回复，未命中转人工。每一步都是人定的，模型只在需要理解或生成的节点介入。它可预测、可测试、出问题能定位到具体节点。

自主规划是「目标给定、路径由模型决定」：模型自己拆解任务、决定调用哪些工具、按什么顺序、要不要重试。它灵活，但每次执行路径可能不同，难测试、难复现，成本和延迟也更高。

判断标准只有一条：你能不能把这件事的合理步骤写清楚？能写清楚，就用工作流；写不清楚、路径高度依赖中间结果，才考虑自主规划。绝大多数企业场景——客服、导购、工单处理、报告生成——都能写清楚。

工程问题一：工具调用要收窄、要幂等

给智能体的工具不是越多越好。工具一多，模型选错的概率上升，权限面也变大。做法是按场景提供最小工具集，写清每个工具的输入输出契约，并区分「只读」与「有副作用」。查询订单是只读，怎么错都不会造成损失；创建工单、发起退款有副作用，必须幂等——同一个请求重复执行不能产生两笔。

有副作用的调用还要加确认与限流：金额、数量、频次超过阈值就停下来要人确认。这条与技术架构里的运行安全措施是同一套。

工程问题二：上下文与状态要显式管理

多轮任务里最容易丢的是状态。用户已经在第二步确认了收货地址，到第六步模型又问一遍，就是因为状态没有作为独立结构维护，全靠对话历史「回忆」。正确做法是把关键槽位（身份、已确认信息、当前进度）抽成结构化状态，每一步读写状态而不是翻聊天记录。上下文窗口是稀缺资源，把该记的记在状态里，比塞进 prompt 更稳。

工程问题三：失败要能回滚、能降级

自主规划一旦走错，代价是它已经调用过的工具。退款退错了、工单开重了，都需要回滚。设计上要求：每个有副作用的步骤记录「补偿动作」，失败时按逆序补偿；补偿不了的，降级为「转人工 + 挂起当前任务」，而不是继续往下猜。

没有回滚和降级的智能体，本质上是在拿生产数据做实验。这也是很多团队把智能体困在演示环境、不敢放量的真正原因。

工程问题四：评测要覆盖路径而非只看结果

确定性工作流测单点即可，自主规划要测「路径」。同一输入，模型这次调三个工具、下次调五个，结果都对但成本差一倍。评测集要记录期望的工具调用序列与步数上限，把「多余调用」也当作错误计分。上线前先把拒答率、引用覆盖率、人工接管率、单次成本这几项钉在看板上，方法见智能体上线前的六个指标。

一个可复用的编排决策表

把智能体做「聪明」不难，做「可靠」才难。可靠来自收窄工具、显式状态、可回滚、按路径评测这四件事，而不是来自更强的模型或更长的提示词。先工作流化，实在需要才给有限的自主权——这是我们反复验证过的、代价最小的编排顺序。