当AI代理拒绝在未获付费时工作

暴露问题

为每个开发人员提供一个强大的本地人工智能代理感觉就像是终极生产力黑客。 但对于大规模运营的组织来说，这是一个 治理和成本陷阱 等待春天。

目前，软件开发生命周期 (SDLC) 中的人工智能革命几乎完全发生在开发人员的笔记本电脑上。 我们正在构建孤立的整体代理循环。 我一直主张转向代理平台，因为我相信这种本地优先的方法只是暂时的。

但在解释该模型为何失效之前，我们先来定义一下“大规模”运行 SDLC 在此背景下意味着什么：将人工智能驱动的开发带入 N 个团队致力于 M 个产品，其中 N 和 M 都大于 10。

我们谈论的不仅仅是单个团队的内部动态，而是真正的多产品组织。

确保组织层面的信任

让我们考虑一个基本事实：法学硕士是概率性的，这意味着人工智能指令仅在一定比例的时间内得到遵循。 想象一下，您创建了一项技能来执行关键业务规则，我们将其称为“企业架构决策”。 ”

由于人工智能的本质，这项技能总是有可能被部分忽视或应用不当。

如果失败率甚至是 10%，并且您将其扩展至 N > 10 个运行数千次迭代的团队，那么从数学上讲，您可以保证某些团队将发布绕过您的全局业务规则的代码。 这导致大量 建筑漂移.

当然，我们可以使用钩子和程序构建确定性护栏来强制验证。 但如果这些是在开发人员的笔记本电脑上本地执行的，我们就会失败 集中可观测性.

CTO 或首席工程师最终对品牌的软件负责。 他们不能仅仅依靠“信任团队”；他们需要制度保障。 当执行机制分散且不可见时，首席技术官如何自信地证明所运送的货物？

管理法学硕士成本和内部经济

当人工智能指令在团队层面本地执行时，组织失去了对执行模型的控制。

开发人员常常陷入一种一刀切的方法。 一项特定技能可能在中级法学硕士上完美运行，但在低成本法学硕士上可能会失败， 但当前的本地工具（例如 Copilot 或 Claude）无法提供简单的方法来根据任务的复杂性将请求动态路由到最具成本效益的模型。

因此，该组织为当地代理拨打的每一个电话支付额外费用。 没有集中式缓存或 智能模型路由，该成本与开发人员和迭代的数量呈线性关系，迅速膨胀为巨额开支。

这给我们带来了最后的财务考虑： 内部经济。如果开发人员构建了一种高效的人工智能技能，随后被多个团队采用， 那么谁承担执行成本？去中心化模型无法提供答案。 我们需要一种方法来准确跟踪使用情况并管理退款，以补偿构建这些共享组织资产的团队。

构建未来的平台

为了解决这些挑战，我们需要从本地黑匣子转向中心化服务。 真正的代理平台应该动态处理人工智能查询——优化模型并利用缓存来大规模控制成本。 它还必须保持一个 财务分类账 用于跨团队退款和 审计日志 以确保架构合规性。

本文的其余部分将利用两个开源标准逐步演示未来的前景： 特工-2-特工 (A2A) 编排和治理协议，以及 代理支付协议 (AP2) 处理内部经济。

A2A任务处于输入需求状态。 可以把它看作是“智能”的需支付402“：

Copy

升级支付

Winston 解析输入所需状态及伴随的支付数据。它会将 isPaymentRequired（task） 判定为真，识别元数据中的payment_required块。 在中央架构师进行任何工作之前，温斯顿必须确定付款授权。

虽然与流程对齐的团队有专门的预算，但管理交易成本则由本地代理人负责。 不过，温斯顿并非盲目花掉球队预算的硬编码。 由于无法自动授权金融交易，它会将请求升级到你这个人类。

你审查报价并用严格的界限验证交易：

你被授权只将这些积分用于这项特定任务。

未来，我们可以设想实施一种学习机制，让温斯顿自动批准日常或可信任务的支出，无需人工干预。

管理内部薪酬”

尽管这些交易使用内部虚拟货币而非真钱，但系统仍要求各方在工作开始前达成可靠的共识。

为了大规模管理这些内部经济，平台依赖集中式账本。作为核心能力，该账本保证提供架构工作的中央服务能从对齐团队的预算中获得合理报酬。

执行AP2 Mandates

代理支付协议（AP2）简要介绍

AP2是一个开放标准， 旨在使人工智能代理能够自主且安全地执行交易。 AP2 不再依赖人工亲自点击“付款”按钮，而是使用加密签名的 Mandates。当用户设定预算或批准报价时，他们会生成授权，赋予代理人可验证且严格限制的支出权限。 虽然最初为全球代理商务而构建，AP2 为内部企业平台提供了完美的框架：它允许本地和中央代理协商成本、证明人工授权， 并在共享账本上安全解决跨团队的退款。

免责声明：由于AP2主要面向全球代理商交易，它本质上依赖于经典电商概念， 如“结账”阶段。虽然这些具体步骤对内部企业平台来说并非绝对必要，但我选择在本POC中实现完整协议， 以展示真正安全的代理间自主性。

在获得人类批准后，温斯顿启动了AP2协议。 它首先是制定并封存结账强制令。在传统电子商务中，这一步将实体商品锁定在购物车中。 在我们的背景下，没有真正的“推车”——但这一步不仅仅是无操作。 在这里，它作为对建筑师报价的加密协议，不可撤销地将具体任务（架构咨询）绑定在约定的价格（800信用点）上。

一旦范围和价格确定，Winston会生成付款授权，指示平台账本从与流媒体对齐的团队预算中暂停所需信用额度。

作为回应，内部支付服务会发出HMAC-签名的令牌。 该代币充当便携式加密支付证明——安全地绑定交易金额、参与方和唯一的 payment_ctx_id.

有了这个令牌，Winston 重新提交初始架构请求，这次附加了任务 ID 和加密证明。 在进行任何计算工作之前，架构师代理会询问支付经纪人以验证授权。 由于这些支付凭证是由买方（温斯顿）而不是卖方生成的，因此系统受到加密保护， 防止伪造。

复制

架构师验证任务已关闭（保持到位），标记任务 payment_verified=true，并立即致电其法学硕士并提出最初的问题。 法学硕士需要更多背景信息。

设计对话

付款确认后，建筑师开始实际工作。 这是多轮 A2A 对话，而不是单个请求/响应。

建筑师提出澄清问题: “每日的具体用量是多少？交易还是营销？有监管限制吗？”

温斯顿以业务背景来回答。 架构师在提出建议之前进行迭代，完善其理解。 当存在 A2A 对话框时发生 input_required 来自“企业架构师”:

… 建筑师要求其第一次澄清。

复制

… 维斯顿回答（他的法学硕士从业务环境中生成答案，或升级到人类）。

复制

当架构师获得足够的信息时，它会通知 Winston 现在可以通过更改状态来工作:

复制

代理网格的实际应用：领域咨询

在本次演示中，这一步是锦上添花。 我之前曾在博客中讲述过我对建立在以下基础上的未来平台的愿景： 代理网格系统，而这种互动完美地说明了它的价值。

在工作流程的这个阶段，中央企业架构师代理具有所有要求。 它可以简单地依靠其内部培训数据来提供建议。 但如果这些知识已经过时了怎么办？如果它建议的通知遗留组件实际上无法处理新负载怎么办？

架构师不是猜测，而是利用网格。 它动态地将技术可行性查询直接委托给 温斯顿@域 （管理通知有界上下文的专用代理。） 领域专家代理评估请求并回复: “每天 50,000 封电子邮件是可行的，但需要增加配额和严格的模板验证。”

这是真实的 领域驱动设计（DDD） 应用于人工智能：领域所有者验证本地可行性，允许中央架构师做出安全、系统的决策。

决策与解决

架构师现在已经收集了足够的背景信息，包括 GDPR 要求和域代理的可行性评估。 它使用所有这些信息最后一次调用其 LLM，并在同一任务上连续发出两个事件：一个工件（结构化决策）和一个状态更新（completed).

建筑师 → 温斯顿：神器（架构决策）

复制

沉降

在发出工件之后，但在将完成状态发送给 Winston 之前，架构师与付款代理结算付款。

这是直接 HTTP 调用，而不是 A2A 消息。

建筑师 → 付款代理: POST /payments/settle

复制

付款代理检查:

• 该授权存在并已结束。

• actual_amount (620) ≤ ceiling_amount (800).

• 任务类型匹配。

然后，它释放对 Winston 帐户的保留，退还差额（800 − 620 = 180 个积分给 Winston），将 620 个积分转移到建筑师的帐户，并返回一个签名的结算代币。

付款代理 → 建筑师: 200 OK

复制

任务完成

直到现在，架构师才结束 A2A 任务。 Winston 通过内置的消费元数据获得最终状态。

建筑师 → 温斯顿: completed

复制

完整图片

A2A 实现真正的代理对代理委托——不仅仅是简单的工具调用，而是具有结构化意图的自主对话。

AP2+402 确保公平的内部定价：代理商在收到报酬之前拒绝工作，授权提供便携式加密证明，并且中立的内部经纪人安全地结算账户。

ADR + 加密证明 使每一个架构决策都完全可审计和确定性可验证——从最初的请求到最终的财务结算。

总结：用代理网格解决陷阱

值得注意的是，此工作流程代表了不久的将来可能出现的情况，而不是当前的行业标准。 然而，我坚信代理开发的未来将不可避免地通过标准化的代理间通信。

通过从孤立的本地巨石转向协作代理网格，我们直接解决了本文开头概述的挑战:

• 摆脱治理陷阱: CTO 不再需要依赖盲目信任。 架构一致性由领域专家动态验证，每个决策都会产生加密密封、集中审计的跟踪。

• 摆脱成本陷阱: 内部经济不再是一个黑匣子。 平台账本管理跨团队退款，中央服务可以智能地将请求路由到最具成本效益的模型。

为了证明这一点，我不仅设计了架构：我还构建了它。

上述场景已在概念验证中完全实现。 在幕后，每个代理都作为一个完全独立的进程运行。 对话有效负载由用于 A2A 对话的官方 Google SDK 提供支持，我集成了 AP2 协议的轻量级自定义版本来处理“402 需要付款”升级和授权验证。

该代码即将准备好公开展示。 您很快就可以通过访问存储库来探索完整的 POC 并自行运行它: github.com/owulveryck/ap2402.