凌晨两点，两个 agent 在互相拆台。
一个盯 CPU，负载过了 80% 就扩 EC2；一个盯账单，花超阈值就缩容。二十分钟里它俩来回拉了好几轮，最后是有人从床上爬起来把它们一起 kill 掉。账单上多了大概 600 美元。
[02:00] scaler-a: cpu > 80% → scale out +2
[02:04] cost-guard: spend > budget → scale in -2
[02:08] scaler-a: cpu > 80% → scale out +2
[02:12] cost-guard: spend > budget → scale in -2
...
[02:2x] <人类从床上爬起来> kill -9
这是 Sarvar Nadaf 九月中那篇 AI Agent vs Agentic AI 里的例子。我看到这段的第一反应不是"agent 冲突真可怕"，是：这两个阈值本来就该丢给编排器统一裁决，为什么让两个 agent 各自揣着一条规则去对撞？
先把话说前面——那篇文章前半篇讲术语，我看完了，没什么想说的。agent 是组件、agentic 是架构，这个层次关系没毛病。但他说"术语混淆让项目多花了三个月"，这个因果我不太信。真实顺序一般反着来：先有人按 agentic 的复杂度把架子搭满，做了三个月才发现业务只需要一个 agent，术语只是事后给这件事补的说法。
值钱的是后半篇那三个烧钱案例。而且它们是同一个 bug。
三个案例，护栏挂错了地方
- 600 美元那次：两条规则互相矛盾，没有冲突优先级。
- 47 次评审循环那次：A 写草稿、B 拒，一直循环到第 47 遍，180 美元干完一件本该 2 美元的事——没设迭代上限。
- 预期 2 美元、实际 200 美元那次：三个 agent 不停派生"更彻底"的子 agent，没人去数自己有几个孙子。
画外音：agent 版的"会开了一下午，纪要三行"。
三件事长得不一样，位置是同一个——护栏全挂在 agent 上，而钱是在 agent 之间花掉的。
每个 agent 配 5 次重试、120 秒超时（作者团队用的硬限制），很规矩。然后编排器把 12 个 agent 的 5 次重试串成一条链，你拦谁去？单点全部合规，组合起来超支。跟前面那个审批链问题是同一个形状。
所以该写的地方是编排器层，不是 agent 层：
# 挂在 orchestration 层，而不是每个 agent 自己身上
LIMITS = {"per_workflow_usd": 3.0, "wallclock_s": 300, "total_iterations": 12}
def step(agent, ctx):
if ctx.spent_usd > LIMITS["per_workflow_usd"]:
raise BudgetExceeded(ctx.workflow_id) # 熔断，不协商
if ctx.iterations > LIMITS["total_iterations"]:
raise TooManyIterations(ctx.workflow_id)
if ctx.elapsed_s > LIMITS["wallclock_s"]:
raise Timeout(ctx.workflow_id)
return agent.run(ctx)
spent_usd 必须是工作流级别的累加值，从编排器一直往下传。挂在 agent 内部的那个计数器，永远只知道自己这一趟花了多少。
这段代码没什么技术含量，我贴出来是因为我见过太多项目把它写在了错的那一层——包括我自己经手的一个。那次的表现形式更蠢：每个子 agent 都老老实实上报 token 消耗，日志里都有，唯独没人做汇总告警。等我们发现的时候，一个内部工具在两周里跑掉的钱，够付大半年的订阅费。这个不算翻车，算慢性缴税。
至于 180 美元那个循环，我倾向于说它不是缺了迭代上限，是缺了"评审意见必须收敛"这个约束。A 写、B 拒、A 改、B 再拒——每一步单独看都很便宜，甚至显得很"认真"。加个 12 次的上限，你得到的只是一个 12 次之后仍然互相看不顺眼的系统，只是它便宜了。上限管住了钱，没管住它到底在干嘛。
那条没人画过的线
评论区里 Jo Do 那句话我抄下来了：
移除一个组件，如果只是质量下降，那它是 agent；如果破坏了工作流契约，那它是 agentic。
这个判据比正文那两套定义都好使，因为它可操作。他还补了一刀：单 agent 只有一个影响面，多 agent 靠一条没人画过的委托链放大影响面；"谁批准编排器所批准的事"，应该放在第一张幻灯片。
作者的审批链例子钝，但准：Agent 1 发现漏洞，Agent 2 自动打补丁，Agent 3 部署到生产。每个 agent 都在自己的规则里行事，合起来等于没有人类批准过这次生产部署。
医疗客户那个 PII 例子更能说明问题。处理客服工单的 agent 看得到 PII，做分析的 agent 不该看得到，中间那个编排器如果把上下文原样递过去，就是合规违规。HIPAA 审计员在生产前逮到了，修了大概两周——重新设计上下文传递层。
我盯着"两周"这个数字想了很久。两周里真正花在写代码上的大概两天，剩下的是在重新决定"哪些字段允许跨 agent 流动、在哪一层被剥掉、剥掉之后下游还够不够用"。这类决定没有任何框架能替你做，也没有哪篇 best practice 清单能直接抄。
这里我纠结了一下要不要写下面这段，因为它听起来像在甩锅给组织，不像技术复盘。但我还是写：这活儿之所以难，是因为它不是技术活儿。
阶段 2 到阶段 3 之间，隔的不是架构图
作者提了个成熟度四阶段，说 2026 年年中多数公司在阶段 2，从 2 跳到 3 主要不是技术问题，是"谁拥有编排层"的组织图问题。
我同意，而且我觉得他手下留情了。
技术上搭一个阶段 3 的骨架，两三个 sprint 足够——共享上下文、基础交接、一个能看的编排器。真正卡死的是：编排层一旦存在，它就成了所有跨团队流程的签字人。谁接？
我这边那个项目，编排层最后是挂在一个临时小组名下的。不是因为没人会写，是因为三条业务线的负责人谁也不肯把审批权交出去，也谁都不肯接过来——交出去等于以后出事不归我管但我也不控制，接过来等于以后所有跨线流程出事都算我的。它就那么在灰色地带撑着：没进变更管理，上线半年走的都是"内部工具，出问题我们自己扛"。你换成 Bedrock Multi-Agent Collaboration 还是 LangGraph，这个归属不会自己长出来。
所以那篇文里"80% 的团队应该从单 agent 开始"，我一开始觉得是句安全的废话，后来觉得它可能是全文最该打印出来贴墙上的句子。不是因为单 agent 便宜，是因为它不需要一个组织先吵出一个签字人。
工具选择那块——作者默认推 Bedrock + AgentCore，理由是开箱就有 IAM 边界、VPC 隔离、CloudWatch 和合规控制，CISO 问数据去哪能答上话。这条我认，但只认一半。它的价值不是技术更先进，是治理这些东西的坑在于"事后补"，而事后补的价钱就是上面那个两周重新设计上下文层。预算是买这些东西最便宜的方式；但如果你的 agent 根本不出 VPC、不碰 PII，那这部分差价就是纯智商税。我自己在上一台机器上就交过一次——买了带合规控制的那档，结果跑的全是内部报表。
LangGraph 呢，作者说自己两次在凌晨两点调试图状态问题。我次数没那么多，但这类编排图的调试体验确实很特殊：节点之间传的东西是隐式的，出错时你看不出是哪一次交接把上下文丢的。这个我到现在也没找到一个舒服的观测方式，基本靠在每个节点前后硬打日志，加上一条贯穿全流程的关联 ID 硬扛。不优雅，但能睡。
规则就一条：任何多 agent 的编排器，在写下第一个 agent 之前，先写死三样东西——全局预算熔断、全局迭代上限、以及一张"这个动作必须人类点同意"的清单。全部挂在编排器上，一份都不许下沉到 agent 里。
至于"谁批准编排器所批准的事"——先逼着大家把那条委托链画出来，画的时候你就会发现没有谁的名字能填上去。那就先别做。
本期缴税：在每个 agent 上设了五道护栏，最后钱是在 agent 之间花掉的。