多步任务编排实战：让 AI Agent 一句话跑完一串操作

2026-11-14 08:43 9 0 0

先给结论：多步编排的本质，是把「一个模糊的大目标」拆成「一串有前后依赖的工具调用」，再用路由和状态决定先跑谁、后跑谁、哪步失败了怎么办。D14 里那个 Agent 是「调一次工具就完事」；真到业务里，往往是「先查订单 → 再判风险 → 调退款接口 → 汇总发通知」，每一步的结果都是下一步的输入。会拆这串链条，Agent 才算真正上岗。

一、什么时候需要编排，而不是单次调用

这一步的输入，依赖上一步的返回（查完订单才知道退多少）；
中间要「判断」：符合条件才走退款，不符合走人工；
某一步可能失败，需要重试或换路；
要同时干几件互不相关的事，最后汇总。

只要命中上面任意一条，就不是「给模型一个工具」能解决的，得把步骤显式编排出来。编排不是让模型自由发挥，而是你定好骨架，模型在骨架上填判断和参数。

二、编排的四种形态

形态	长啥样	典型场景
顺序链	A 完事才跑 B，B 完事才跑 C	查订单 → 退款 → 通知
分支路由	按条件走不同支路	风险高走人工，风险低自动退
循环重试	失败就重来，直到成功或超限	接口超时、库存不足
并行汇聚	几件独立的事同时跑，最后合并	同时查订单 / 物流 / 发票再汇总

真实业务常常是这四种的混搭：先并行查几样，再顺序处理，中间带分支和重试。

三、实战：一句话自动处理退款（骨架）

用户说「帮我把订单 A123 退款」，Agent 要自动跑完下面这条链。下面是一个把步骤显式列出来的可跑思路：

def step_query(order_id):
    return db.query_order(order_id)          # 查订单，返回金额/状态

def step_risk(order):
    return risk.check(order)                 # 风控：返回 "auto" / "human"

def step_refund(order):
    return pay.refund(order["id"], order["amount"])   # 调退款接口

def step_notify(result):
    push.send("退款结果：" + result)         # 发到微信/飞书（呼应 D6）

STEPS = [step_query, step_risk, step_refund, step_notify]

def run_workflow(order_id, max_retry=2):
    ctx = {"order_id": order_id}
    for step in STEPS:
        for attempt in range(max_retry + 1):
            try:
                out = step(ctx)              # 执行，结果写回 ctx
                ctx.update(out if isinstance(out, dict) else {"_last": out})
                break
            except TransientError:           # 只重试可恢复的错
                if attempt == max_retry:
                    return "步骤失败，转人工"
    return "全部完成"

这个骨架的关键点：步骤是「数据」不是「写死的 if」，以后加一步只是在 STEPS 里追加；每步失败只在「可恢复错误」上重试，且带次数上限防死循环。把 db / risk / pay / push 换成你的真实服务（或 D9 里封装的 MCP 工具）即可落地。

四、状态与上下文怎么管

只带必要状态：每一步往 ctx 写关键字段，别把整段对话历史往工具里塞，否则 token 爆得快。
步骤结果要可序列化：方便中途落库、断点续跑，也方便排查哪步出的错。
模型只做「判断和填参」：比如「风险高低」让模型判，但「调退款接口」这句执行必须你写死，别让模型自由拼 SQL。

五、错误与重试策略

错误类型	处理
网络超时 / 限流	重试（指数退避），限次数
参数校验失败	不重试，直接转人工 / 回问用户
下游明确拒绝（如余额不足）	不重试，按业务分支处理
模型选错步骤	步骤边界写死，限制模型只在「分支判断」处发挥

六、常见坑

坑	原因	规避
把整段历史喂给每步	token 暴涨、变慢变贵	只传 ctx 里的必要字段
无限重试	下游挂了还在打	设最大次数 + 只重试可恢复错
让模型直接拼执行语句	SQL 注入 / 误删	执行层你写死，模型只出参数
分支条件模糊	模型判断飘	分支用明确阈值 / 枚举，别写「差不多就行」

七、FAQ

Q：编排和 D14 的 Agent 循环是一回事吗？ 是同一套「模型选下一步」思想的放大版。D14 是单工具短循环；编排是把多个短循环按依赖串成大流程，多了状态管理和分支。

Q：一定要用框架吗？ 不一定。上面那种「步骤列表 + 循环」几十行就能写；步骤多到要可视化、要被人非技术同事改流程时，再考虑 D11 里的 Dify / n8n。

Q：怎么和微信 / 飞书通知打通？ 把「发通知」做成最后一步（如上 step_notify），接 D6 的推送能力即可，编排完自动把结果推到群里。

小结

多步编排 = 把大目标拆成有依赖的步骤 + 用路由控顺序 + 用状态管上下文 + 用重试兜失败。先别神化「自动化」，从「顺序链」起步，把每一步的执行写死、只让模型做判断和填参，跑通一条再补分支和重试。需要可视化拖流程或给非技术同事用时，再搬出 D11 的 Dify / n8n。具体执行层接口、风控规则以你业务系统当天实现为准。