AI Agent 的竞争焦点已经变了：从工具调用走向完整运行系统
截至 2026 年 8 月，AI Agent 的竞争正从模型与工具调用转向长时运行、状态恢复、协议互操作、权限控制和可靠性评测。
时间范围：截至 2026 年 8 月 18 日。 这份判断主要基于过去 12 个月的厂商技术资料、开放协议、论文与独立评测。
AI Agent 正从「大模型套一个工具调用循环」，升级为一套完整的任务运行系统：
模型负责判断，运行时负责持续执行，协议负责连接，沙箱负责隔离，权限系统负责约束，评测系统负责证明它是否真的可靠。
过去一年最清晰的进展来自工程系统：主要平台开始分别补上状态保存、失败恢复、大型工具目录、权限、审计和长时间执行。各项能力的成熟度并不相同，长时可靠性尤其没有解决。
Agent Runtime 开始取代简单工具循环
早期 Agent 的典型结构很简单：
用户目标 → 模型思考 → 调用工具 → 返回结果 → 再思考几家主要厂商正在把 Agent 架构补成下面这种形态：
目标
↓
规划与任务分解
↓
持久状态 / 检查点
↓
工具发现与程序化编排
↓
隔离沙箱执行
↓
验证、回滚与重试
↓
人工审批或结果交付OpenAI 新版 Agents SDK 已经把沙箱、文件操作、命令执行、补丁修改、记忆、恢复和长任务编排纳入统一运行时。LangGraph、Microsoft Agent Framework、AWS AgentCore 和 Claude Agent SDK 也出现了相似的能力组合。12
这些产品的趋同说明，几家主要平台正在押注同一组运行时能力：
- 模型本身不应该直接承担状态管理；
- 长任务必须支持 checkpoint 和恢复；
- Agent 必须获得结构化的环境反馈；
- 执行环境必须与模型编排层分离；
- 人工接管必须成为运行时原语，而不是提示词中的一句要求。
技术可用性：上述组件都已有正式产品或公开实现；组合后能否稳定运行，仍取决于具体任务和验证器。
长时 Agent 变成后台任务系统
最新 Agent 不再要求用户保持会话在线。最新运行时正在普遍支持：
- 异步后台执行；
- 跨小时任务；
- 会话恢复和任务句柄；
- 上下文压缩；
- 子任务隔离；
- 失败后从 checkpoint 继续；
- 并行执行多个任务；
- 执行中等待用户补充信息。
OpenAI 的运行时支持外部化状态和沙箱恢复。Anthropic 引入上下文编辑、记忆工具和托管 Agent。MCP 的新任务扩展也采用任务句柄、状态查询和中途输入，而不是让一次请求长期阻塞。Claude Sonnet 4.5 发布时，Anthropic 表示模型在其内部测试中可以在复杂、多步骤任务上保持专注超过 30 小时。3
真正有商业价值的 Agent 往往需要等待 API、审批、人类输入或外部系统状态。普通聊天循环无法可靠支撑这些任务。
长时间运行仍然不等于长时间可靠。METR 的研究显示，模型能够以 50% 成功率完成的任务时长仍在快速增长；2026 年 1 月发布的 Time Horizon 1.1 把任务集从 170 个扩展到 228 个，其中 8 小时及以上任务从 14 个增至 31 个。4
成熟度：数小时任务已经可用；跨天、跨周任务仍然高度依赖工作流约束。
工具调用转向按需发现和程序化编排
工具数量扩大之后，传统 function calling 出现了三个问题：
- 工具定义占满上下文；
- 相似工具容易被选错；
- 每次工具调用都需要模型重新推理，成本和延迟不断累积。
Anthropic 的 Tool Search 代表了一条新路线：系统初始只提供少数基础能力，Agent 在需要时才搜索和加载具体工具定义。Anthropic 的示例把工具上下文从约 77K tokens 降到约 8.7K tokens，节省约 85%。5
Programmatic Tool Calling 又进一步改变了工具调用方式。模型先生成一段编排代码，代码再并行调用工具、过滤数据和处理中间结果，最后只把必要结果交还给模型。
这套机制具有三个直接价值：
- 工具目录可以容纳数百或数千个条目，而不必把全部定义一次塞进上下文；工具发现的准确率、权限隔离和结果验收仍需单独解决；
- 大量中间数据不再污染模型上下文；
- 多次工具调用不再等于多次完整模型往返。
最新 Agent 因此正在形成两级能力目录：
Agent
├─ 常驻基础工具
├─ 工具搜索
│ ├─ 数据库能力
│ ├─ 企业系统能力
│ ├─ 浏览器能力
│ └─ 专业领域能力
└─ 代码执行器负责批量编排技术可用性：按需加载与程序化编排已经有公开实现和量化样例；大规模生产还要验证工具发现、权限与验收链路。
Agent 协议形成分层技术栈
行业已经不再试图用一个协议解决所有问题。最新协议生态出现了明确分层：
| 协议层 | 主要职责 |
|---|---|
| MCP | Agent 连接工具、数据和外部系统 |
| A2A | 独立 Agent 之间发现、委派和交换任务 |
| AG-UI | Agent 与前端之间传输流式事件 |
| A2UI | Agent 用受控的声明式格式生成界面 |
| AP2 等授权协议 | 支付、审批、意图证明和审计 |
Google 的协议指南已经把 MCP、A2A、UCP、AP2、A2UI 和 AG-UI 分别放到工具连接、Agent 通信、商业、支付授权和人机交互等不同层次。6
MCP 已经从单一厂商项目进入 Linux Foundation 下的 Agentic AI Foundation。Anthropic 在 2025 年 12 月披露，当时已经有超过 10,000 个活跃公开 MCP Server，Python 和 TypeScript SDK 的月下载量合计超过 9700 万次。这些项目方统计说明 MCP 的生态正在快速扩张，却不能单独证明协议在生产环境中的可靠性。7
A2A 负责 Agent 与 Agent 的跨框架通信。一个 Agent 可以通过能力描述和任务接口与另一个 Agent 协作，而不必暴露内部提示词、记忆或完整工具清单；身份、授权、状态和错误处理仍然需要系统另外落实。
标准化仍然不等于稳定。MCP 在 2026 年继续调整会话、任务和可观测性设计，A2A 1.0 也包含破坏性变更。团队目前应该把协议适配放在独立网关层，避免业务代码直接绑定某个协议版本。
成熟度：MCP 的采用面已经较广，但规范仍在变化；A2A 和 Agent UI 协议更接近早期标准化阶段。
多 Agent 从角色群聊转向受控并行
第一代多 Agent 系统通常让几个角色互相讨论。这个方案容易出现重复推理、上下文膨胀、错误共识和成本失控。
在需要并行的工程实践中，多 Agent 更适合被设计成受控的分布式任务系统：
- 调度器根据依赖关系拆分任务；
- 子 Agent 获得隔离的工作区与最小权限；
- 子 Agent 并行执行相互独立的任务；
- 主 Agent 负责合并结果、处理冲突和最终验收；
- 系统记录每个子任务的输入、轨迹、成本和产物。
多 Agent 最适合三类任务：
- 可以明确拆分的代码、研究或数据处理任务；
- 不同子任务需要不同工具或权限；
- 并行执行可以显著缩短总时长。
多 Agent 不适合目标模糊、依赖高度耦合或需要统一创作判断的任务。多个 Agent 也不会自动产生高于单 Agent 的判断力。多个 Agent 有时只会更快地产生更多错误。
适用判断：受控并行在可拆分任务上已经有工程价值；开放式多 Agent 协作仍缺少足够的可靠性证据。
编程 Agent 仍然领先
编程领域成为 Agent 的第一块成熟市场并不是偶然。代码环境具备四个独特条件：
- Agent 可以读取完整状态；
- 测试可以提供明确反馈；
- Git 可以支持回滚和差异审查；
- 沙箱可以限制错误影响。
OpenAI 的 Agent-first 工程实践把隔离 worktree、日志、指标、trace、测试和 Agent review 放进同一反馈回路。工程师的工作因此从直接写代码，逐渐转向设计环境、约束、验收标准和反馈机制。OpenAI 同时指出，这套实践高度依赖具体仓库结构，长期架构演化仍需机械化约束和持续清理。8
同样的方法更容易扩展到其他拥有明确验证器、可控数据权限和可回滚副作用的领域：
- 数据分析；
- 财务对账；
- 文档结构化处理；
- 安全扫描；
- 测试和质量保证；
- 有明确业务规则的运营流程。
开放式管理、战略决策和跨组织协调仍然更难，因为这些任务缺乏可执行的客观验证器。
成熟度：部分编程 Agent 已经进入生产使用；其他领域能走多快，取决于是否能提供同样清晰的验证、权限和回滚条件。
Agent 评测转向可靠性科学
静态排行榜越来越难解释真实能力。
一项 2026 年的可靠性研究评估了 15 个模型、两个基准和 12 项可靠性指标。研究发现，模型准确率的提升明显快于一致性、鲁棒性和可预测性的提升。一个模型可以获得更高的平均得分，但它在重复运行、环境变化、提示改写或工具故障时仍然表现不稳定。9
OSWorld 2.0 包含 108 个长时桌面任务，人类完成这些任务的中位时间约为 1.6 小时，这说明任务本身具有较长操作链。最强受测系统的二值完成率只有约 20.6%，部分完成得分约为 54.8%。人类用时与系统得分不是同一指标；两组数据分别说明任务长度和系统完成情况。10
这说明当前 Agent 往往可以完成大量步骤，却无法稳定完成整个工作流。
Online-Mind2Web 也提醒人们注意评测环境差异。部分旧 Web Agent 基准曾报告接近 90% 的成绩；在任务、成功定义和系统版本不同的在线评测中，代表性系统的成功率约为 61%。两组数字不能直接横比，但静态环境与真实网站之间的差异足以改变结论。11
下一代评测将重点测量：
- 同一任务重复五次是否得到一致结果；
- 环境变化后是否还能完成；
- 工具暂时失败后能否恢复；
- Agent 是否知道自己可能失败；
- 任务耗时、token 和工具成本；
- 人工接管次数；
- 部分完成度和副作用；
- 真实线上环境与静态沙箱之间的差距。
成熟度：评测方法正在重构，单一排行榜的可信度正在下降。
Agent 安全转向权限工程
聊天模型已经需要管理数据、工具和内容风险。Agent 在这些风险之外，还会持续采取行动，因此系统必须进一步控制「它能做什么、以谁的身份做、做到哪一步要停」。
Agent 的主要攻击面包括：
- 间接提示注入改变 Agent 目标；
- Agent 误用合法工具；
- 身份或权限被滥用；
- 长期记忆被污染；
- 第三方 MCP Server 或插件形成供应链攻击；
- 一个 Agent 的错误通过 A2A 传播；
- 代码执行器、浏览器或终端越权；
- 自动任务之间形成级联故障。
OWASP 的 Agentic Applications 风险框架把 Agent 行为劫持、工具滥用、身份与权限滥用、提示注入、记忆污染、权限提升和数据泄露列为重点风险。12
最新安全架构正在形成五层防线：
1. 独立 Agent 身份
2. 最小权限和默认拒绝
3. 工具调用前的策略检查
4. 沙箱、网络和数据隔离
5. 轨迹审计、异常监控与人工审批监控本身也不是最终答案。METR 的实验发现，更强的模型既更擅长监控其他 Agent，也更擅长绕过监控。推理轨迹在部分设置中可以把捕获率提高超过 50 个百分点，但推理摘要、上下文长度和隐藏计算都会削弱效果。13
成熟度：Agent 安全已经出现较完整的风险分类和防护模式，但防御效果仍随任务、攻击方法和监控条件显著变化。
当前成熟度地图
已有正式产品、生产工具或公开案例：
- 沙箱执行；
- checkpoint 与任务恢复；
- MCP 工具连接；
- 会话状态和短期记忆；
- 轨迹、日志、指标与 tracing；
- 人工确认和关键动作审批；
- 编程 Agent；
- 有明确规则的垂直工作流。
正在高速扩张：
- 按需工具发现；
- 程序化工具编排；
- A2A 跨 Agent 协议；
- 长时间后台 Agent；
- Agent 驱动的声明式 UI；
- 独立 Agent 身份；
- 多 Agent 并行执行；
- 跨模型、跨框架的任务可移植性。
仍然被高估：
- 完全自主的通用数字员工；
- 无限长期记忆；
- 多 Agent 自动产生群体智能；
- 一个高排行榜分数代表真实生产能力；
- 提示注入可以被彻底解决；
- Agent 可以在没有验证器的开放环境中长期稳定运行；
- 单纯扩大上下文窗口就能解决长任务问题。
未来 6–12 个月
运行时会成为主战场
框架之间的基础 agent loop 已经高度同质化。竞争将转移到 durable execution、状态和记忆、沙箱、身份与权限、trace 回放、成本、协议兼容与评测。Microsoft 把 AutoGen 与 Semantic Kernel 合并为 Agent Framework，就是生态收敛的典型信号。2
企业将为 Agent 分配独立身份
在高权限场景里，让 Agent 长期借用员工的完整账号会放大越权和归因风险。事故压力、审计要求和最小权限原则会推动更多企业采用 Agent 专属身份、短期凭证、任务级授权、参数级权限、审批额度、完整行动归因和可撤销委托。
私有、动态的评测会替代静态榜单
随着公开基准趋于饱和，企业更有必要建立自己的任务集，并持续改变数据、界面、权限和失败条件。公开分数仍可用于初筛，却不足以预测具体工作流的可靠性。
更有价值的指标将包括：
- 80% 或 95% 可靠任务时长；
- 每个成功任务的真实成本；
- 严重错误率；
- 人工介入率；
- 恢复成功率；
- 权限违规率；
- 任务完成后的副作用。
垂直 Agent 将领先于通用 Agent
未来一年，我更看好有限领域内的 Agent：它们拥有清晰工具、明确权限、结构化状态和客观验收标准。相比开放式通用 Agent，这些系统更容易接手流程中的人工操作，并减少企业为重复流程投入的人力。
给技术团队的架构建议
如果现在建设生产级 Agent，我建议采用七层结构：
1. 模型层
多模型路由，不绑定唯一供应商
2. Agent Runtime
状态机、checkpoint、重试、超时和任务恢复
3. 工具网关
MCP 或内部统一工具协议，支持按需发现
4. 执行层
文件、代码、浏览器和桌面沙箱
5. 身份与策略层
独立身份、最小权限、参数级规则、人工审批
6. 可观测性层
Prompt、tool call、状态变化、成本、trace 和产物回放
7. 评测层
私有动态任务、重复运行、故障注入和线上抽样审计团队应该避免三种设计：
- 团队不应该把完整业务状态长期塞进模型上下文；
- 团队不应该让模型直接持有高权限长期凭证；
- 团队不应该用单次成功演示代替重复可靠性测试。
最终判断
从正式产品、公开生产案例和协议生态看，AI Agent 已经不再只是概念验证；但独立评测表明，可靠自治仍然没有过关。
当前真正值得关注的突破来自三件事：
- Agent 能在受控环境中运行更久；
- Agent 能连接更多工具而不淹没上下文；
- 系统开始用权限、恢复、监控和评测约束 Agent。
判断一个 Agent 系统是否值得部署，单项 benchmark 已经不够。更关键的问题是：模型能否稳定完成任务、失败后恢复、越权时停止，结果能否验证。这组运行时能力，比「Agent 操作系统」这个口号本身更重要。
References
- 1The next evolution of the Agents SDK
openai.com
- 2Introducing Microsoft Agent Framework
azure.microsoft.com
- 3Introducing Claude Sonnet 4.5
anthropic.com
- 4Time Horizon 1.1
metr.org
- 5
- 6Developer’s Guide to AI Agent Protocols
developers.googleblog.com
- 7
- 8
- 9
- 10OSWorld 2.0
arxiv.org
- 11Online-Mind2Web
arxiv.org
- 12OWASP Top 10 for Agentic Applications for 2026
genai.owasp.org
- 13
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.