一条企业周报脚本，通常从四个动作开始：读取 Jira 的 P0 工单，拉取 Git 主分支提交，交给模型总结，再把结果发到 Slack。需求一变，脚本里便陆续长出 if-else、JSON 校验、超时重试和补救 Prompt。脚本仍然能跑，却越来越不敢改。
难点已经从“提示词怎么写”转到了运行过程：Git 超时后从哪里继续，Jira 数据缺失时能否生成报告，Slack 发送前要不要人工确认，以及每次重试会增加多少模型调用。
脚本开始堆补丁，就是换架构的信号
手动 Prompt 链没有彻底失效。输入输出稳定、工具行为确定、任务失败后可以整体重跑时，固定流程通常更省事。Tony Bai 的文章标题很直接：《停止构建 AI Agent！这里有 5 个更简单的 LLM 工作流模式，能解决 90% 的问题》。标题里的 90% 是作者的判断，不能当成所有项目的通用基准，但提醒很有价值：不要为了使用 Agent，先把简单问题做复杂。
真正需要编排层介入的，是会分支、依赖外部工具、需要保存中间状态的流程。此时继续补 Prompt，只会让异常处理散落在脚本各处。Agent 编排要接管的是状态、路由、重试和权限，提示词只是其中一个节点。
周报流程里，先把状态存下来
以 Jira、Git、Slack 这条链为例。Jira 已经读取成功，Git 调用却发生超时，合理的处理方式是保留 Jira 结果，只重试 Git。Git 多次失败后，报告应明确标记数据缺失，而不是让模型猜测提交内容。
下面是概念性伪代码，不对应 AutoGen 或 LangGraph 的真实接口：
# 概念性伪代码，不对应 AutoGen 或 LangGraph 的真实接口
flow = Workflow(goal='生成本周产品周报')
flow.add('jira', JiraSkill(scope='P0', permission='read_only'))
flow.add('git', GitSkill(branch='main', permission='read_only'))
flow.add('summary', SummaryAgent())
flow.add('slack', SlackSkill(mode='draft'))
flow.on_error('git', retry=3, then='mark_missing_and_continue')
flow.before('slack', require='human_approval')
这段配置把两个决定写清了：Git 调用失败时最多重试 3 次；Slack 只生成草稿，发送动作需要确认。中间结果应落在可恢复的状态中，进程中断后也不必从 Jira 节点重新开始。
上下文超过模型限制时，也可以启用预先批准的备用路径：分别总结 Jira 工单和 Git 提交，再合并两份摘要。这样的调整有边界、有记录，比运行时临时生成一条未知路径更容易审计。
MCP 管接入，编排层管运行
人人都是产品经理的一篇文章把 Agent Skills 概括为从静态工具调用走向动态技能封装，并讨论了 Anthropic、Microsoft 和 OpenAI 的不同路径。Anthropic 提出的 Model Context Protocol（MCP），重点解决模型与外部工具之间的互操作问题。
一个可用的 Skill，至少要说清输入参数、返回格式、权限范围和错误行为。过去写在 Prompt 里的“请调用 search_web()”，可以被整理成带有明确接口的技能。网页接口变化或调用受限时，编排层能够识别错误类型，再决定重试、降级或停止。
无论团队评估的是 AutoGen v0.5 还是 LangGraph 0.2，都要把协议层与编排层分开看。MCP 负责工具如何被发现和接入；编排层负责顺序、分支、状态与审批。模型侧即使使用 Claude，MCP 也不会替团队决定何时重试、何时回滚、何时交给人工。
自愈先处理故障，不要现场发明权限
腾讯云开发者社区一篇修改于 2026 年 4 月 29 日的文章，把 API 超时、模型幻觉等问题列为自愈工作流需要面对的生产变量。把“自愈”落到工程上，可以拆成几类受控动作：
- 保存错误堆栈、工具返回和当前节点状态；
- 区分超时、格式错误、数据缺失与权限拒绝；
- 按策略执行重试、降级、暂停或转人工；
- 从最近的有效节点恢复，并留下完整记录。
权限错误尤其不能交给模型自由处理。周报流程发现 Jira 访问受限时，正确动作是停止并申请授权，而不是继续探测权限更高的管理接口。读取 Jira 和 Git 可以限定为只读，向 Slack 写入消息则增加审批节点。
让模型根据错误堆栈生成修复建议没有问题，但生成的代码更适合进入人工审查队列。直接改写并执行生产逻辑，会让一次接口故障升级为权限和审计问题。
别拿市场数字代替成本核算
一篇知乎专栏文章给出的数字是：AI Agent 市场从 2025 年的 76 亿美元增长到 2026 年预计的 108 亿美元；文章还引用 Gartner 预测称，40% 的企业应用将在 2026 年底嵌入 AI Agent。同一来源提到，近三分之二的组织正在实验 Agent，成功扩展到生产的不足四分之一。
这些是二手行业数据，适合用来观察市场热度，不能直接证明某个团队上了 Agent 就会省钱。真实账本要看每次运行调用了多少模型、为什么重试、工具费用是多少，以及人工审核花了多少时间。
路由也不必一律交给大模型。“今天有几条提交记录”可以由数据库查询或固定规则完成；摘要任务可以评估较小模型；冲突归因和路径规划再交给能力更强的模型。即便考虑端侧 3B 模型，也要用实际任务测试质量与延迟，参数量本身给不出答案。
没有前后基准、任务样本和统一成本口径，就不要轻易承诺“效率提升三倍”或“三到四周回本”。这类数字写起来醒目，对选型没有帮助。
选工具前，把这些问题问完
- 工作流能否保存每个节点的状态和检查点？
- 能否限制重试次数，并只恢复失败节点？
- 每个 Skill 的读写权限是否可以单独配置？
- 模型的路由选择、Prompt 版本和工具返回能否追溯？
- Slack 写入、代码执行等动作能否强制加入人工确认？
- 每次运行的模型与工具成本能否单独核算？
AutoGen v0.5 或 LangGraph 0.2 的选择，应放在这些问题之后。框架名称解决不了权限边界，也不会自动补齐状态存储和成本监控。
固定、短小的 Prompt 链仍然值得保留。等脚本开始被重试 Prompt、异常分支和权限补丁包围，再把状态恢复、工具接入和执行策略移到编排层。
“自进化”也需要收窄到可验收的范围：系统可以在已批准的路径里调整顺序、重试和降级，每次变化都能追溯。至于让 Agent 现场改写生产代码，先把它放回人工审查队列。
