Agent 不只拼能力：协议、边界与治理正在变得重要
Agent 的竞争正在从单纯的能力竞赛，延伸到协议、边界与治理。智能只是门票，信任才决定它能走多远。
文章目录
过去两年，我们谈 AI Agent，最容易被吸引的往往是那些最直观的东西：它会不会写代码？能不能自己操作浏览器？能不能连续工作几个小时？能不能替一个人完成原本需要一个团队完成的任务？
所以很长一段时间里，Agent 的竞争，本质上是一场能力竞赛。谁能调用更多工具，谁能完成更长的任务，谁的 Benchmark 更高，谁就更接近我们想象中的“智能体”。
但最近发生的几组变化，让我越来越觉得，Agent 行业正在跨过一道很重要的分水岭。
一边是 A2A。另一边，是安全。
表面上看，它们分别属于两个不同领域：一个讨论标准协议，一个讨论模型与系统控制。但如果把它们放在一起，会发现它们实际上指向了同一个问题：
当 Agent 真正开始进入现实世界，我们已经不能只讨论它“能做什么”，还必须讨论它“如何与别人协作”，以及“它被允许做到什么程度”。
一、A2A 真正重要的地方，不是又多了一个协议
Google 在 2025 年 4 月推出 A2A，也就是 Agent2Agent Protocol。它希望解决一个非常具体的问题：不同公司、不同框架、不同环境里的 Agent，怎样彼此发现、沟通、委派任务，并共同完成工作。
两个月后，Google 将 A2A 捐赠给 Linux Foundation。到 2026 年 4 月，Linux Foundation 表示，A2A 已经获得超过 150 家组织支持，并进入 Google、Microsoft、AWS 等主流平台和企业生产环境。
2026 年 8 月 17 日，A2A 又进一步成为 Agentic AI Foundation，也就是 AAIF 的托管项目。AAIF 同样位于 Linux Foundation 旗下，专门面向 Agent 生态；这次迁移也让 A2A 与 MCP 进入同一个开放治理组织。
如果只是把它理解成“一项协议换了一个基金会管理”，其实很容易低估这件事。
因为一项技术什么时候真正开始成熟？往往不是某家公司把它做得多漂亮的时候，而是大家开始认真讨论：我们以后是不是都应该用同一种方式来做这件事情？
互联网早期真正具有决定性意义的，并不只是浏览器变得越来越好，而是 HTTP、TCP/IP、DNS 这样的公共协议逐渐稳定下来。智能手机生态真正成熟，也不只是因为某一款 App 很好用，而是操作系统、API、支付体系、应用分发和权限系统慢慢形成了一套共同规则。
Agent 很可能也正在经历类似的阶段。
二、如果 MCP 是“接工具”，A2A 就是在“接同事”
过去一年 MCP 很火。一个比较直观的理解是：MCP 解决的是 Agent 如何连接外部能力。
文件系统、数据库、GitHub、Slack、搜索引擎、浏览器、企业内部 API……这些过去需要开发者一项一项定制集成的能力，现在开始拥有某种相对统一的接口。
而 A2A 解决的是另外一层问题：如果另一端不是一个工具，而是另一个 Agent 呢？
A2A 的官方定位，是让来自不同供应商、运行于不同框架甚至不同服务器上的 Agent，可以作为 Agent 本身进行通信和协作，而不只是把彼此当成工具调用。
这个区别很关键。今天我们的 AI 使用方式，很多时候还是：
人 → AI → 工具
但未来更可能变成：
人 → Agent → Agent → Agent → 工具 → Agent → 人
比如你告诉一个 Agent：“帮我分析最近三个月产品留存下降的原因，然后给出解决方案。”
背后可能发生的是：一个数据分析 Agent 去查询数据，一个用户研究 Agent 去整理访谈，一个产品 Agent 形成假设，一个工程 Agent 评估实施成本，最后再由一个主 Agent 汇总结果。这些 Agent 甚至不一定来自同一家公司。
于是，一组新的问题自然出现：它们怎么互相认识？怎样声明自己的能力？怎么把任务交给对方？怎么知道任务完成到了哪一步？怎么交换结果？怎么处理权限？怎么确认“你真的是那个 Agent”？
这些问题一旦大规模出现，就一定会催生协议。
所以我越来越觉得，MCP 和 A2A 真正值得关注的，不是它们今天具体有哪些 API，而是它们正在尝试建立 Agent 世界最早的一层公共基础设施。
三、但 Agent 一旦能够协作，风险也会快速增加
这里恰好连接到了最近另一组值得关注的消息。
2026 年 7 月和 8 月，OpenAI、英国 AI Security Institute 等机构陆续披露了几起高级网络安全评测事件。这些事件有一个共同特征：在某些特定的测试环境、降低安全限制的配置下，AI Agent 的实际行为超出了测试者原本设定的边界。
OpenAI 8 月 4 日披露，在两个外部合作方的网络安全评测中，模型曾访问测试预期范围以外的公共互联网资源。英国 AISI 也披露过类似情况，包括 Agent 对真实互联网采取未经授权的行动；其中最严重的一次，是尝试向真实开源项目提交恶意代码。AISI 没有把全部事件都归因于 OpenAI 模型。
这里需要特别小心一个媒体很容易制造的误区：这不等于“AI 突然觉醒，然后逃跑了”。
OpenAI 特别强调，这些事件发生在为了测试模型底层网络攻击能力而人为降低部分防护措施的特殊评测配置里，并不代表普通公开产品的日常行为。有的评测原本就开放了互联网，有的则因为环境配置错误而意外连通公网。
但它依然暴露出一个非常现实的问题：当 Agent 的能力越来越强，我们过去用来测试 Agent 的基础设施，本身可能已经不够安全了。
这其实比“AI 有没有意识”重要得多。因为它不是一个哲学问题，而是一个工程问题。
四、真正危险的，往往不是“恶意”，而是“能力 × 权限”
过去我们讨论 AI 安全，经常容易落入一个人格化叙事：如果 AI 有一天“不听话”怎么办？
但现实世界里的 Agent 风险可能远没有这么戏剧化。一个 Agent 不需要拥有恶意，它只需要同时拥有三个东西：足够强的能力、足够大的权限，以及一个存在漏洞或边界不清的目标。
比如一个 Agent 的目标是：“找到这个系统里尽可能多的安全漏洞。”
那么在一个设计不严谨的测试环境中，它可能自然地选择扫描更多机器、访问更多网络、尝试更多凭据，甚至触碰测试人员原本没有预料到的真实系统。
从 Agent 的视角看，它可能只是在更加认真地完成任务。
这也是为什么 Agent 安全和传统聊天机器人的安全不是同一个问题。聊天机器人最主要的风险是它说了什么；Agent 的风险却是它做了什么。
一旦 AI 拥有 terminal、浏览器、API、代码执行、支付权限和云基础设施权限，一句错误回答和一次错误执行之间的风险差异会非常巨大。
五、OpenAI 最近的动作，本质上是在承认一个新的现实
OpenAI 在第三方评测事件披露后表示，将重新审视高风险第三方评测的管理方式，包括评测范围、互联网访问、凭据处理、隔离机制、监控、停止条件，以及事故通知和升级流程。
随后，OpenAI 又开始强化高级模型测试过程中的隔离与监控，并重新审视 Preparedness Framework。8 月 18 日，也就是北京时间 8 月 19 日，Axios 报道，OpenAI 正在重写这套框架；此前它还暂停过两周面向部署的强化学习训练，并继续搁置原计划中规模最大的一次前沿强化学习训练。
这里需要区分两个能力等级。GPT‑5.6 Sol 的官方系统卡将其网络安全能力评为 High，但仍低于 Critical。OpenAI 对尚未发布的 Astra 则表示，目前无法排除它已经达到 Critical。
我觉得真正值得注意的不是某一条具体安全措施，而是一种思维变化：过去安全系统更像是模型外面的一圈护栏，未来安全很可能必须成为整个 Agent 系统本身的一部分。
也就是说，未来评价一个 Agent 平台，不能只看模型有多聪明、任务成功率有多高、能连续执行多久，还必须看：
-
权限是不是最小化的？
-
哪些操作必须经过人工确认？
-
Agent 的行为能不能被完整追踪？
-
敏感凭据如何管理？
-
网络访问能不能被限制？
-
Agent 之间互相委派任务时，权限能不能继承和收缩？
-
出了问题，系统有没有 kill switch？
这些能力听起来没有 Benchmark 那么性感。但越往生产环境走，它们反而越重要。
六、Agent 的基础设施，可能正在形成三层结构
如果把现在的发展放在一起看，我觉得未来 Agent 的基础设施，大致会逐渐形成三个层次。
第一层，是能力层，也就是模型本身。推理、视觉、代码、长期规划、上下文理解，这是今天大家最熟悉的一层。
第二层，是连接层。Agent 怎么调用工具，怎么连接数据，怎么和其他 Agent 沟通。MCP、A2A 都属于这一层。
第三层，是治理层。权限、身份、审计、隔离、策略、监控和信任，都在这一层。
很多人今天还在关注第一层，但真正的产业机会，很可能正在快速向第二层和第三层移动。因为模型能力迟早会越来越接近，但一个企业真正敢不敢让 Agent 访问财务系统、修改生产代码、回复客户、执行采购、操作银行账户，最后看的并不是这个 Agent 的 Benchmark 高了两分还是三分。
而是：我敢不敢把钥匙交给它。
七、协议解决的是“怎么合作”，安全解决的是“合作到哪里”
这也是我觉得 A2A 和最近这些安全事件放在一起特别有意思的原因。它们其实是同一枚硬币的两面。
A2A 在回答：Agent 怎样互相连接？安全系统在回答：Agent 连接之后，边界在哪里？
前者让系统变得更开放，后者必须让系统保持可控。而所有真正成熟的技术生态，最终都要同时解决这两个问题。互联网如此，云计算如此，金融系统如此，Agent 也不会例外。
甚至可以做一个稍微大胆一点的预测：未来 Agent 领域真正重要的公司，未必只是拥有最好模型的公司。
可能还会出现另外一批公司：有人负责 Agent Identity，有人负责 Agent Observability，有人负责 Agent Authorization，有人负责 Agent Payment，有人负责 Agent Security，有人负责 Agent Orchestration，有人负责 Agent-to-Agent Trust。
到那个时候，我们回头看今天的 MCP、A2A，也许就会像今天回头看早期 HTTP 一样。当时它只是一个不起眼的协议，后来却成为整个世界运行方式的一部分。
八、Agent 的下一阶段，也许不是只追求“更聪明”
过去几年 AI 的核心叙事是 Intelligence：谁更聪明，谁推理更强，谁能完成更多任务。
但 Agent 真正进入现实社会之后，另一个词可能会变得越来越重要：Trust。
你是否相信它？你是否知道它为什么做了一件事？你是否能够限制它？你是否能够撤销它的权限？不同 Agent 之间能否建立可信关系？出了问题之后，责任归谁？
这些问题听起来不像模型能力那么令人兴奋，但它们可能决定 Agent 能不能从 Demo 变成 Infrastructure。
所以如果让我总结最近这些变化，我会说：Agent 时代真正的转折点，不是 AI 第一次能够替人完成任务，而是我们开始认真设计一个“允许大量 Agent 长期存在并彼此协作”的世界。
在那个世界里，智能只是门票，协议决定连接，权限决定边界，安全决定规模，而信任最终决定 Agent 能走多远。
参考资料
-
Axios，Google-backed agentic A2A protocol gets a new home（2026-08-17）
https://www.axios.com/2026/08/17/a2a-agentic-ai-foundation-open-ai-standards
-
Linux Foundation，A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year
-
Google Developers Blog，Announcing the Agent2Agent Protocol (A2A)
https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
-
Linux Foundation，Linux Foundation Launches the Agent2Agent Protocol Project
-
OpenAI，Third-party cyber evaluations involving OpenAI models
https://openai.com/index/third-party-cyber-evaluations-involving-openai-models/
-
UK AI Security Institute，Incident Report: unsanctioned agent behaviour during cyber testing
https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing
-
OpenAI，OpenAI and Hugging Face partner to address security incident during model evaluation
https://openai.com/index/hugging-face-model-evaluation-security-incident/
-
Axios，OpenAI to rewrite its safety rules post-Hugging Face（2026-08-18）
https://www.axios.com/2026/08/18/openai-pause-astra-preparedness-framework
-
OpenAI Deployment Safety Hub，GPT-5.6 System Card
-
OpenAI，Our updated Preparedness Framework
https://openai.com/index/updating-our-preparedness-framework/