企业级 AI 代理集中化：破解治理与成本困局

在企业规模化部署 AI 编码代理的实践中，「每位开发者一台本地代理」的模式正面临治理与成本双重瓶颈。本文作者结合自身实践，提出以 Google A2A（Agent-to-Agent）协议与 AP2（Agent Payment Protocol，代理支付协议）为基座的「代理网格」集中式架构，并已构建出可运行的 PoC。

本地优先模式的三大困局

作者将「在 N 个团队、M 个产品上规模化运行 AI 开发」作为讨论起点（N、M 均大于 10），并指出三个核心问题。

治理失效：LLM 的概率性本质意味着关键业务规则存在被部分忽略的可能。即便失败率只有 10%，在数千次迭代后也会「数学上必然」出现绕过全局规则的代码，引发架构漂移。本地工具缺乏集中可观测性，CTO 难以系统化地保证交付质量。
成本失控：本地工具（如 Copilot、Claude 等）通常采用「一刀切」的模型调用方式，无法根据任务复杂度动态路由到最具性价比的模型，且缺少集中缓存，组织需为每次调用支付溢价。
内部经济不清：当某团队开发出高效 AI 技能并被多团队复用时，谁承担运行成本？去中心化模型无法回答这一计费与激励问题。

集中式「代理网格」架构

为破解上述困局，作者主张将 AI 调用从本地黑盒迁移到集中化服务，构建具备以下能力的代理平台：

动态模型路由与缓存，以控制规模化成本；
跨团队计费账本（ledger），支持内部成本分摊；
加密可审计日志，确保架构合规。

在此基础上，文章进一步引入 Google 的 A2A 协议负责代理间编排与治理，并定制轻量版 AP2 协议处理「402 Payment Required」式的升级与凭证校验，让「代理拒绝无凭证工作」成为可执行的业务规则。

仍属前瞻探索

作者强调，该工作流描绘的是「可能的近未来」而非行业现行标准。相关 PoC 已基本完成，代码即将在 GitHub 仓库（owulveryck/ap2402）公开，底层使用 Google 官方 A2A SDK，每个代理以独立进程运行，便于读者自行验证。文中所列的集中可观测性、智能路由与计费账本思路，与当前多代理框架普遍将信任、成本与执行绑定在客户端的现实形成对照，提示企业在落地 AI 编码代理时需提前规划治理与计费基础设施。