摘要：文章讨论了多代理系统面临的挑战，包括审计追踪、代理真实性验证以及恶意代理威胁。现有协议在消息格式和身份验证方面有所帮助，但缺乏语义决策日志记录、能力证明和对抗恶意代理的有效手段。需要开发新的代理感知解决方案，如对话防火墙和基准测试管道，以确保多代理生态系统的安
文章讨论了多代理系统面临的挑战，包括审计追踪、代理真实性验证以及恶意代理威胁。现有协议在消息格式和身份验证方面有所帮助，但缺乏语义决策日志记录、能力证明和对抗恶意代理的有效手段。需要开发新的代理感知解决方案，如对话防火墙和基准测试管道，以确保多代理生态系统的安全和信任。
译自：AI Agents Can Talk, But Can We Trust Them?
作者：Abhishek Asthana
自从 Google 发布 Agent2Agent (A2A) 协议，紧接着 IBM/BeeAI 发布了 Agent Communication Protocol (ACP) 协议之后，人们一直期望能够出现一个多代理生态系统，在这个系统中，各个代理可以自主地相互通信，并在无需人工干预的情况下完成任务。
考虑以下这个简单的用例。
在现实世界中，您通常会打电话给您的旅行社，然后旅行社再联系其他人来预订机票或通过致电导游来规划活动。在代理的未来（或现在！），您的旅行社将被一个 与其它AI代理对话的AI代理所取代，这些AI代理可以预订机票或规划活动。（此时，我们不会深入研究这些代理如何完成这些任务，无论是通过使用 MCP 工具还是调用其他代理。）
需要牢记的关键一点是，这些代理可能跨越组织边界运作。您可能正在与 Expedia 或 Booking.com 等网站上的代理进行交互。机票预订代理可能属于航空公司，而 Showaround 或 TourHQ 等在线导游公司可能拥有活动规划代理。
虽然 A2A 和 ACP（以下简称“这些协议”）为代理的发现、共享上下文和通信提供了一种通用的“语言”和一套规则，而不管它们使用的底层技术栈如何，但跨组织的代理交互增加了显著的复杂性和风险。
在这篇文章中，让我们讨论其中的一些挑战，看看如何使用现有技术来解决这些挑战，并找出差距。
当多个代理协作完成一项任务时，追踪决策过程的复杂性会呈指数级增长。
考虑另一个稍微复杂一些的用例。一家公司有一个 SaaS 应用程序，并且同时使用 AWS 和 Azure（或者 GCP，我并不反对它们！）作为底层基础设施。这两个平台都有 SRE 代理，可以帮助调试和修复任何基础设施问题。该公司有自己的 SRE 代理，可以与这些平台代理进行通信，为它们提供上下文和额外的信息。
考虑以下示例事件和由此产生的审计追踪链：
事件：数据库连接超时导致 500 错误审计追踪链1. [10:15:32] 公司-SRE-代理：检测到高错误率（23% 的 500 错误）- 数据来源：应用程序日志，指标聚合- 决策：升级到基础设施调查2. [10:15:45] 公司-SRE-代理 → AWS-SRE-代理：- 请求：“分析 db-prod-cluster 的 RDS 性能”- 交换的凭证：具有只读 RDS 权限的临时访问令牌- 身份验证：证书链已验证3. [10:16:12] AWS-SRE-代理：分析完成- 发现：“CPU 利用率正常，连接池容量为 98%”- 建议：“扩展连接池或调查连接泄漏”- 访问的数据：RDS CloudWatch 指标，连接池统计信息4. [10:16:20] 公司-SRE-代理 → Azure-SRE-代理：- 请求：“检查 Application Gateway 后端运行状况”- 跨云上下文：共享事件 ID #INC-2024-0610-0015. [10:16:35] Azure-SRE-代理：分析完成- 发现：“后端池显示间歇性运行状况检查失败”- 根本原因已识别：区域之间的网络延迟峰值6. [10:16:50] 公司-SRE-代理：关联分析- 决策：实施连接重试逻辑 + 扩展 RDS 连接- 采取的措施：部署配置更新，扩展 RDS这个场景突出了几个审计追踪的挑战：
数据主权： AWS-SRE-Agent 访问了 RDS 数据 — 是否有记录确切共享了哪些数据？决策归属： 如果修复失败，是公司代理的关联逻辑问题还是云代理的建议问题？合规性： 是否有任何证据表明只有 授权代理访问了生产系统？跨平台关联： 我们如何合并来自三个不同组织系统的审计日志？这两种协议都提供了一系列功能，有助于为代理间的通信创建基本的审计追踪。最重要的是，一种通用的语言提供了结构化的消息格式，这些格式 标准化了代理交换信息的方式，以确保消息数据可以被一致地记录。这些协议还通过 ID 和消息线程提供基本的会话跟踪，这允许对相关的消息进行顺序分组，从而有助于跟踪单个多步骤对话的流程。它们还可以使用标准化的发送者/接收者寻址方案和使用时间戳对消息进行基本的时间排序来识别任何代理。
而这些协议没有提供：
语义决策日志记录： 协议侧重于消息格式，而不是推理内容。这种缺乏语义决策日志记录忽略了上下文，使得推理链的重建变得困难。联邦审计标准： 几乎不可能关联来自不同公司代理网络的审计追踪，因此无法追踪哪个代理影响了哪个决策。防篡改审计追踪： 如果没有内置的加密验证，很难信任日志的完整性和正确性。这并不是说目前的 系统根本无法捕获代理系统的审计追踪。远非如此！许多跨组织系统使用同步（REST API）或异步（例如，消息队列）机制进行通信，并使用 OOTB 工具和技术（共享 Kafka 集群、Redis 流、区块链等）或行业特定的解决方案来管理审计追踪。问题在于，这些预先存在的解决方案可以回答以下问题：
谁在什么时间调用了什么服务谁访问了哪些数据哪里发生了什么错误代理为什么做出特定的决定？代理之间是如何相互影响的。什么样的推理导致了结果？代理是否按照设计的方式运行。简而言之，大部分基础设施都已可用，但需要扩展具有代理感知能力的功能，这些功能可以追踪代理决策的“为什么”和“如何”，而不仅仅是“什么”和“何时”。
这两种协议都使用代理公布的能力来发现适合正确工作的代理。例如，如果一个代理需要生成一个文档的摘要，它可以查询注册表或发现端点，以找到另一个将“文档摘要”列为其能力之一的代理。
但是，我们如何确保一个代理像它声称的那样有能力？
一个代理可能会通过以下方式谎报其能力：
能力膨胀： 代理夸大其能力。例如，它声称具有高级推理能力，但使用简单的基于规则的响应。对于执行文档摘要的代理来说，这可能无害，但对于执行股票价格高级分析的代理来说，这可能是灾难性的。凭证欺骗： 代理出示伪造的证书或培训出处。性能下降： 代理最初公布了其能力，但随着时间的推移而下降，并且没有更新其能力。这些协议解决了代理身份验证和注册问题，现有的基础设施可以处理身份验证，这已经完成了大约 80% 的工作。证书可用于确认代理的组织身份，数字签名或 mTLS 可用于确保消息是真实的且连接是安全的。
但是，对于能力证明（证明代理的能力声明）、培训出处（验证其训练数据或模型的真实性）或能力漂移检测（识别性能/结果漂移）没有标准的解决方案。
由于现代问题需要现代解决方案，因此我们需要提出新的解决方案或使用现有解决方案来增强这些解决方案。
例如，使用基准测试管道或模型漂移检测框架等工具，持续监控代理的性能与基线进行比较，将有助于确保它仍然能够按照其公布的方式执行其工作。使用新的模型签名方法将有助于验证代理的模型。能力证明是一个棘手的问题，将需要可以充当“AI 智商测试”的基准测试服务。大规模运行这些管道和服务可能是一个值得解决的工程问题！
这些协议假设代理对其能力是诚实的，这显然是第一步。但是，如果我们从软件方面的经验中学到了什么，那就是系统中的并非所有参与者总是值得信赖的。
这很好地过渡到我们的最后一个问题。
一个代理谎报其能力可能会严重阻碍系统的性能，但是如果该代理是主动恶意的并且已被创建为损害系统呢？
这并不是一个未来主义的反乌托邦情景，而是目前正在发生的事情。（阅读 这里 和 这里。）您可能已经阅读了 OWASP Top 10 GenAI 安全风险，这些风险可能会影响模型和 AI 应用程序。因此，当开发代理系统时，遵循这些建议变得更加关键。
但是，多代理系统有一些独特的挑战：
大规模的社会工程： 代理可以通过对话操纵其他代理，索取敏感或机密的 数据，或通过损害投票/决策过程来操纵共识。Prompt 注入： 受损的代理可以将恶意 Prompt 注入与其他代理的对话中，导致下游代理执行意外的操作，并在代理网络中传播恶意指令。信息级联故障： 恶意代理可以提供损坏或有偏差的信息，以降低性能或给出错误的结果，并且这些错误或偏差会随着它们在代理网络中传播而放大。特洛伊木马能力： 代理可能会执行合法的职能，但也可能具有隐藏的恶意行为。您会看到，最大的未解决问题是语义安全，即保护免受在含义/内容级别而非仅仅是技术级别上运行的威胁。传统的安全假设是确定性的、可预测的系统。代理安全需要防御可能具有创造性、适应性和欺骗性的系统。
其中一些挑战可以通过使用现有的解决方案和实践来解决。对不受信任的代理交互使用沙盒协作（隔离环境）和网络分段（受保护的网络区域）可能是防止恶意代理的关键但简单的方法。
但是，为了对抗对话操纵，我们需要新的解决方案，例如分析通信背后含义的“对话防火墙”和可以发现操纵企图的影响检测算法。红队演练可以在加强我们的代理以防御此类攻击方面发挥关键作用。
我们之前讨论过基准测试管道，以监控外部代理的行为和性能，以发现性能漂移。这些管道也可以为我们的代理运行，以不断 监控数据质量趋势并检测其响应中任何渗透的错误或偏差。还可以更新系统设计以采用交叉验证系统，其中多个代理验证关键信息。
代理通信协议虽然是重要的第一步，但要确保 多代理生态系统中的安全和信任 还有很长的路要走。虽然它们为代理彼此交谈提供了“语言”，但它们并没有解决跨组织交互带来的更复杂挑战。虽然一些现有的工具和实践可以提供帮助，但我们最终需要新的、具有代理感知能力的解决方案来解决这些问题。安全、可靠的代理生态系统的未来取决于我们构建这些解决方案的能力。
来源：汽车你我他