ai agent 自动化流程

你可能已经能让 Agent 调通一两个工具，但一放到真实业务里就开始出问题：某一步卡住整个流程不动、并发一上来就限流、某个模型挂了没有备选、跑完也不知道哪一步慢哪一步贵。这篇不重复讲协议和原理，只给一套从任务拆解到工具编排的落地顺序，以及每一步该先定什么、出问题时按什么顺序查。

你可能已经能让 Agent 调通一两个工具，但一放到真实业务里就开始出问题：某一步卡住整个流程不动、并发一上来就被限流、某个模型挂了没有备选、跑完也不知道哪一步慢哪一步贵。这篇不重复讲协议和原理，只给一套从任务拆解到工具编排的落地顺序，以及每一步该先定什么、出问题时按什么顺序查。

下面五个环节是递进关系，前一步定不下来，后一步就只能靠猜。建议按顺序过一遍，每节末尾的检查点如果答不上来，就别急着往下走。

先把任务拆成能单独验收的步骤

拆解的粒度标准只有一个：这一步能不能单独跑、单独验。一步里塞两次模型调用加一次写文件，出错时你根本不知道是模型判断错了，还是文件路径写错了。宁可步骤多一点，也不要出现无法定位的复合步骤。

每拆出一步，就顺手写清三件事：输入是什么、输出长什么样、失败算不算致命。这三条不写下来，后面的编排全是猜。尤其是「失败算不算致命」，它直接决定这一步要不要重试、要不要降级、能不能跳过继续。

• 区分确定性步骤和模型步骤：能写死的规则别交给模型，模型只负责判断和生成那一段；
• 把只读的信息收集放在前面，把写操作放后面，顺序本身就是一种保护；
• 拆完画一张步骤依赖图，标出哪些能并行、哪些必须等前一步，这决定后面并发怎么设；
• 给每步标一个「失败后怎么办」：重试、跳过、降级还是终止，四选一写清楚；
• 步骤命名用动词加对象，日志里一眼能看懂是哪一步出的问题。

工具编排：注册、参数与调用顺序

每个工具在被挂上去之前，先定边界：能读什么、能写什么、参数哪些必填哪些可选。越界的东西一律不给，不是不信任模型，而是减少它做错选择的空间。

模型选错工具或参数拼错是高频问题，而且往往不是模型能力问题，是工具描述写得含糊。工具名和描述要写清「什么时候该用」，而不是只写「这个工具是什么」。

超时、重试与并发的档位怎么定

超时最容易被设成一个全局值，然后发现单次调用太短、整条流程太长。正确的做法是拆成三档：单次接口调用、单个步骤整体、整条流程。三者的关系是后者包住前者，任何一档都不能等于另一档。

1. 先测延迟基线把每个工具在正常负载下的耗时记下来，取一个偏保守的值作为单次调用的超时，而不是拍脑袋定。
2. 再定单步超时单步超时等于这一步内部所有调用超时之和再加上一点余量，这样单步超时才有意义。
3. 最后定流程超时流程超时按业务能接受的最长等待来定，超过就直接判定失败并走降级，不要让它无限挂在那里。
4. 并发按额度倒推先量出延迟基线，再按接口的调用额度倒推并发数，超了就用队列排队，而不是硬冲触发限流。
5. 给每步设最大循环次数Agent 在一个工具上来回打转是很常见的失败模式，硬性截断比事后分析更划算。

重试只对可恢复错误生效：超时、限流、网关错误这些值得重试；参数错、鉴权错、权限不足这类重试多少次结果都一样，只会白白消耗额度。重试要带退避，别固定间隔猛打。

并发上不去时先查哪里

• 是接口限流还是自身连接池不够，两者的处理方式完全不同；
• 并发高了以后单次调用耗时是不是明显变长，是的话瓶颈不在你的编排；
• 有没有某一步串行拖住了整条链路，这种时候加并发没用，要改结构；
• 重试是不是在放大流量，失败重试叠加并发会让实际请求量远超预期。

降级路径与日志：出事时能接住、事后能复盘

降级不是等出事再想，是设计阶段就该给关键步骤准备退化方案。常见的有三类：换备用模型、换更简单的提示词、直接转人工。哪种合适取决于这一步对结果质量的要求，判断标准是「差一点的结果能不能接受」。

日志要记的东西不多，但要记全：步骤名、耗时、用的哪个模型、输入输出的摘要、错误类型、重试次数。少一样，复盘时就得靠猜。

把「贵」和「慢」分开看，token 消耗和耗时是两个独立的排查方向，混在一起很容易误判。

上线前跑一遍小评测

上线前不需要大而全的评测集，准备一组固定用例就够，但要覆盖三类：正常路径、边界输入、以及你已知会失败的场景。用例不用多，能稳定复现历史问题的十几条，就比没有强很多。

改动前后都跑同一组，看三个指标：成功率、平均耗时、平均消耗。任何一个明显变差，都不该直接上。模型或提示词一换就重跑，别等线上出问题才发现。具体的对照数字不用记在这篇文章里，到站内评测页面核对当时的数字更可靠。