Agent 编排如何限制权限、成本与执行步数

Agent 能自己决定下一步，不代表它应该拿到所有工具和权限。原文的核心主张是：把自主判断留给模型，把预算、权限、审批和停止条件交给外部工作流。路径越难预测，外围控制越要明确。

这篇值得读的地方，是它把「要不要上 Agent」拆成了每一步该给多少自由。对正在接入 AI 编程、工具调用或多步任务的团队，这比先挑一个多 Agent 框架更实用。不过，文章后半段带有 Unmeshed 的产品推广，需要把通用原则和厂商宣称分开看。

能用规则解决的步骤，为什么要交给 Agent？

传统编排（orchestration）在运行前就确定路径：先校验输入，再调用服务，最后保存结果。模型可以参与其中，但不一定拥有选择下一步的权力。

Agentic orchestration 的区别在于，部分路径由模型在运行时决定。例如，它可能根据一次工具返回的结果，选择继续查询、换个工具，或者结束任务。编排层负责约束这些选择：谁接着执行、能看到什么上下文、可以调用哪些工具、什么时候重试或终止，以及何时必须等待人工审批。

这里还要区分工作流和 Agent。工作流规定流程的边界，Agent 在其中负责需要判断的环节。框架则更靠近 Agent 内部，组织它如何调用模型、使用工具和循环执行。

作者建议把自主性看作一个逐级调节的旋钮：

规则能确定的事情，用规则；输入比较杂、但输出任务明确的事情，用一次模型调用；只有后续步骤无法提前确定时，才考虑 Agent 循环。

升级到 Agent 的理由，应该是简单方案解决不了任务。

文档摘要、翻译、反馈分类通常不需要自主循环。即使一个业务需要 AI，也可以让固定工作流负责输入校验和审批，只把中间一个需要判断的步骤交给模型。原文援引 Anthropic 和 Google Cloud 的指导支持这种分工，但没有提供不同方案的成本或成功率对照。

五种编排模式，先挑能解决问题的最简单一种

文章列出五种常见模式：顺序、并行、路由、编排器与工作节点，以及评估循环。

顺序模式适合存在明确依赖的任务，前一步的结果交给后一步。并行模式适合彼此独立的子任务，分别处理后汇总。这两种模式都可以完全由固定代码控制，不需要模型决定执行路线，因此更容易预测和排查。

路由模式根据输入选择处理分支。编排器与工作节点模式则由一个协调者拆分任务、安排执行，适合事先无法列全步骤的工作。评估循环会检查结果，再决定是否返工；它必须设置最大迭代次数，否则错误的退出条件可能让流程一直运行。

模式选完，协作问题才刚开始。作者强调了几项具体约束：交接时要规定传递哪些字段、使用什么格式；所有 Agent 围绕同一份运行状态工作；每个 Agent 只获取完成任务所需的上下文；多个 Agent 能修改同一记录时，要提前定义冲突处理规则。

这些问题不能靠一句「请互相配合」解决。

尤其是共享状态和异常恢复，它们属于基础设施。所谓持久化执行（durable execution），可以理解为任务的进度能够保存下来，进程崩溃或重新部署后仍能恢复。至于如何避免恢复时重复产生副作用，原文没有继续展开，实际选型时仍需确认。

生产环境要管住五件事，提示词承担不了这些责任

作者提出的五项控制，分别是预算上限、工具权限范围、审批关卡、步骤限制和完整追踪。

预算上限要约束每个 Agent 的开销。接近额度时，可以限流或切换到更便宜的模型。步骤限制则约束执行次数和总时长，避免循环失控。两者需要分别设置：步数少的任务也可能很贵，便宜的调用也可能无限重复。

工具权限必须由运行时执行。模型只能调用绑定给它的工具，不能因为提示词里写了「不要删除数据」，就把一个拥有全部能力的接口直接交出去。

提示词可以描述权限，运行时才负责执行权限。

审批关卡用于付款、删除等难以撤销的动作。工作流在执行前暂停，获批后继续。完整追踪则记录每次模型调用、工具调用和费用；日志帮助解释发生了什么，评估帮助判断结果是否合格，这两件事不能互相替代。

原文引用 Gartner 的预测：到 2027 年底，超过 40% 的 Agentic AI 项目可能被取消，原因包括成本增长、业务价值不明确和风险控制不足。这个数字是预测，并非已经发生的项目失败率，更不能用来证明某个平台一定能降低失败率。

Unmeshed 在文章中被定位为外围工作流引擎。按作者介绍，它提供持久化状态、重试、工具绑定、每个 Agent 的预算上限、规则决策引擎、人工审批和完整运行历史，并支持 MCP 原生工具及模型无关接入。

它不负责训练模型，也不是跨供应商路由的 LLM gateway。LangChain、CrewAI 或自行编写的循环仍放在 worker 内部，由 Unmeshed 承接外层执行和治理。文章称其由 Netflix Conductor 的创建者打造，但没有提供可复现实验来验证这些能力的效果。

我的判断

我认同文章把讨论起点放在「每一步需要多少自主性」上。对开发团队来说，这能直接影响实现复杂度：确定性校验交给代码，有限判断交给模型，需要连续探索的部分再使用 Agent。这样也更容易定位到底是哪一层出了问题。

不过，文章是一套架构建议和产品介绍，没有展示他们团队的真实项目、运行样本、费用变化或失败率对照。「更便宜、更可靠」在这里主要是工程推断，收益究竟多大，仍要用自己的任务验证。

五种模式也不全是 Agent 专属。顺序和并行本来就是常见工作流能力，采用它们不必然需要新平台。对只有一次模型调用的功能，现有服务加上超时、权限校验和日志可能就够用；需要跨进程恢复、长时间等待审批时，持久化工作流的价值才更明显。

标题里的 root access 更像是权限过大的比喻，正文没有讨论操作系统 root 权限、容器隔离或沙箱实现，不能把工具白名单直接当成完整的执行安全方案。

另外，原文援引 Gartner 称，数千家 Agentic AI 厂商中大约只有 130 家具有真实相关能力，但没有交代认定标准。比这个数字更有用的，是作者给出的选型建议：要求供应商展示一次失败任务的完整运行历史，检查失败之后究竟如何处理。

能拿来做什么

• 给现有 AI 功能拆一次步骤，把每一步标成固定规则、单次模型调用或自主循环。Node 服务中的参数校验、额度判断和审批条件应优先保留为确定性逻辑，再检查哪些环节确实需要模型判断。
• 为 AI 编程工具明确可读写的目录和可执行的命令，并在工具执行层落实限制。若接入提交或部署动作，把审批放在动作发生之前，避免只依赖提示词提醒。
• 给所有循环同时设置最大步数、超时和费用上限，并记录停止原因。达到限制后，要能看出它是在等待工具、反复返工，还是持续获得无用结果。
• 评估编排平台时，用同一个任务检查工具调用失败、进程重启和等待审批三种情况。沿着运行历史确认状态能否恢复、工具权限是否生效，以及费用是否可追踪。