Agent OS 的下一场竞争：从“能调用工具”到“能交付结果”

一位新员工下周一入职，Agent 接手了准备工作。

它读取录用信息，列出材料清单，给本人发提醒，再调用接口建好账号。演示到这一步，通常已经够让人兴奋。可真实流程会接着发问：录用信息批准过没有？岗位或入职日期变了，哪些操作要撤回？账号建好了，设备申请却失败了，这件事算不算办完？如果人最后没来，谁去把权限收回？

这些问题，几乎都不取决于模型能不能多答对一道难题。它们落在流程状态、权限边界、跨系统一致性，以及组织里谁对什么负责。

理解 Agent OS，可以从这里开始。本文说的 Agent OS，不是某个具体产品，也不是要替代 Windows 或 Linux 的新操作系统，而是一套让 Agent 持续工作的逻辑平台：在明确授权下推进任务，交出可以检查、追溯和接管的结果。

所以它的基本单位不该是一轮聊天，而是一项任务。聊天记录能说明“说过什么”，却回答不了“做到哪了、还缺什么、该谁拍板”。一项任务要有目标、负责人、权限、预算、截止条件、运行状态和验收标准。少了这些，Agent 再聪明，也很难进入正式的业务流程。

五层能力，加一个控制平面

如果只把架构切成“上面的应用”和“下面的模型”，最难的问题都会被塞进中间那根连接线里。更实用的切法是五层能力：

• 应用与交互：个人助理、岗位 Agent、流程应用、任务工作台。解决人如何委派、审阅和接管工作。
• 任务运行时：规划、调度、状态持久化、中断恢复、协同。解决工作如何跨会话、跨天持续推进。
• 上下文与数据：检索、记忆、业务语义、产物版本与血缘。解决如何拿到正确且有权使用的信息。
• 工具与互操作：API、MCP、A2A、浏览器、桌面、事件。解决如何连接系统、采取行动和交接。
• 模型与计算：模型网关、推理、隔离沙箱、存储、网络。解决如何安全、经济、稳定地运行。

层级表示能力分工和依赖，不是每个任务都要逐层走一遍的固定流水线。

还有一些能力放不进任何一层：身份与委托授权、安全策略、版本发布、追踪评测、预算和审计。它们组成控制平面，作用在每一次读取、委派和执行上。任务运行时管“怎么推进”，控制平面管“允不允许、控不控得住”。

顺着一项任务看，整条链可以压成一句话：目标与验收，有界授权，受控执行，结果核验，留证改进。任何一环缺位，系统都容易停在漂亮的演示阶段。

应用层：少一点万能助手，多一点完整任务

应用层最容易被看见，也最容易同质化。写邮件、总结会议、回答制度问题都有用，但产品如果只给单点能力，整段工作过程还得用户自己拼。

更有价值的变化，是从“帮我处理这份内容”走向“帮我推进这件事”。个人助理要在邮件、日程、文档和业务系统之间保持连续，同时分清工作身份和个人身份；岗位型 Agent 要懂岗位规则、例外情形和交接责任。客服问题被回复了，不等于客户的问题解决了；入职材料整理好了，也不等于员工具备了到岗条件。

市场上并不缺这类工具。Salesforce Agentforce 已经提供面向岗位和流程的 Agent，Dify、阿里云百炼也都提供 Agent 与工作流的构建能力。所以机会不能简单说成“缺某个岗位的 Agent”，更该问的是：某类任务放进一家企业的真实流程里，为什么还是没法稳定完成？

沿着这个问题看，有三块空间值得重视。

一是跨系统流程。入职、采购、客户开户、合同流转，常常要穿过好几个系统。每个系统内部也许已经很完善，但系统之间的等待、核对和异常处理，还是靠人在补。Agent 的价值是减少这部分协调成本，而不是给每个系统再加一个聊天窗口。

二是专业交付。研究、开发、分析、写文档，都不该以“生成了一份东西”收尾。报告有没有来源，软件有没有通过测试，数据口径是否一致，资料变了能不能跟着更新，这些验收条件才决定产物能不能进入下一道工序。

三是管理者的任务工作台。一个人同时盯着多个 Agent 时，最想知道的是：哪些完成了，哪些在等自己决定，哪些有风险，哪些得马上接管。系统该呈现的是待确认的变更和对应证据，而不是几十页执行记录。

说到底，应用层要省的是人的注意力。Agent 做得更多，人却要检查得更多，效率未必真的提高了。

基础设施并不空白，缺口在衔接处

从公开文档看，Agent 周边的服务已经相当丰富。Temporal 提供持久执行；LangGraph 用检查点机制保存图的运行状态；Composio 做工具接入和认证管理；Browserbase 提供云端浏览器；E2B 提供隔离的代码执行沙箱；Mem0 提供记忆层；Langfuse 做追踪与评测；Microsoft Agent 365 则把重点放在 Agent 的注册、访问控制和治理上。

这说明机会不在于把同样的组件再造一遍。真正该追问的是：这些组件接起来之后，还剩哪些业务问题没解决。至少有五处。

能恢复运行，不代表能安全重试。 Agent 发出一个创建账号的请求，随后网络超时。系统不知道是请求没送到，还是账号已经建好、只是响应丢了。直接重试，可能多出一个重复账号；直接停下，可能留下一个没人管的账号。可靠执行需要幂等标识、状态查询、核验和必要的补偿流程。持久化运行时能保存进度，外部系统的行为却仍要逐个适配。检查点不是事务，“再跑一次”也不等于安全：邮件发出去了，恢复快照不能让收件人没看过；订单履行了，回滚本地状态也撤不回现实后果。

能访问应用，不代表有权执行某个动作。 “允许 Agent 使用人事系统”是过于宽泛的授权。真实业务要的是更细的边界：它代表谁，只能处理哪些员工，能看什么、改什么，授权什么时候失效，哪些动作必须再确认一次。MCP 规范里已经有授权和安全方面的内容，但协议层的支持替代不了企业自己的动作级策略。任务暂停一天再恢复，用户可能已经调岗，权限可能已经收回，系统不能凭昨天拿到过授权就继续今天的操作。

能保存记忆，不代表记住的是有效事实。 企业记忆和个人偏好不是一回事。制度会修订，岗位会变动，同一个员工在不同系统里可能有不同的标识。一条信息曾经正确，现在也可能已经失效。所以记忆服务还需要来源、有效期、版本、权限和纠错机制，尤其要分清用户偏好、任务状态和业务事实这三样东西。聊天里一句“好像已经批了”，不能自动变成一条已批准的正式记录。

能追踪调用，不代表任务已经完成。 调用链全部返回成功，只说明系统执行了某些操作，证明不了流程达到了业务目标。入职准备是否完成，要核对材料、账号、设备和必要审批的真实状态；报告是否合格，要检查证据和口径；软件是否可用，要看用户实际能不能操作。验收可以由确定性规则、业务系统状态、自动测试和人工检查一起完成，但不能让生成结果的 Agent 自己宣布成功。

能互相通信，不代表能放心协作。 MCP 主要标准化 Agent 与工具、数据之间的连接，A2A 主要解决独立 Agent 之间的发现、委派和结果交换。通信协议不会自动统一业务语义，也不会替各方约定交付质量、成本上限和失败责任。一个 Agent 把任务交给另一个 Agent，只是协作的开始：接单方承诺什么，怎么验收，什么时候终止，能不能再转包出去，都需要协议之外的机制。

五个值得验证的产品方向

把这些缺口转成产品，我会优先看五类。需要说清楚：它们是需求假设，不是对市场空白的断言。

第一类是任务契约与验收服务。把模糊的要求变成双方确认的交付条件，保存执行证据，独立检查结果。它的价值不在于生成一张好看的任务卡，而在于减少返工和复核。该看的指标是验收通过率、争议率，以及人花在检查上的时间是否真的下降。

第二类是企业动作授权网关。在外部动作执行之前，检查身份、委托关系、操作对象、时效和审批状态。它必须处在实际的执行路径上，不能只是写在提示词里的规则。权限撤销之后，在途任务如何停下来，也是这个产品的一部分。

第三类是跨系统可靠执行与恢复服务。围绕具体业务提供幂等、状态核验、异常接管、补偿和对账。壁垒往往来自对业务状态的理解，而不是多一个重试按钮。有些场景可以逆向操作，有些只能补救，有些必须交给人判断。

第四类是带权限的组织记忆与业务语义服务。把分散的信息对应到同一个员工、客户或合同，识别版本与口径，并让检索和派生记忆跟着权限变化走。它要解决的不是“存得更多”，而是“此时此地，该信哪一条”。

第五类是人机协同的任务工作台。把异常、审批、变更对比、证据和接管放在同一处。好的交互不是让人在每一步都点一次确认，而是让低风险的工作自动推进，把人的注意力留给真正需要判断的地方。

技能与插件的供应链、跨 Agent 的服务计量和结算，也值得关注。能力包需要来源审查、权限声明、版本回归和撤回机制；按结果付费，则得先解决“什么叫完成”。这些方向能不能撑起独立产品，还要看使用规模、买方预算和生态成熟度。

先做垂直闭环，别先造大而全的 OS

从架构看，Agent OS 覆盖的能力很多；从产品看，这不意味着一个团队要同时建所有层。

对缺少现成开发者渠道和运行规模的团队，更可行的路往往是先做一个垂直任务闭环：挑高频、验收标准明确、跨系统协调成本高、风险又可控的任务，复用成熟的基础设施，把主要精力放在业务语义、异常处理和结果核验上。

还拿入职准备说。第一步可以只做材料检查、制度匹配、异常提示和审批建议，由负有责任的人确认之后，再开放明确授权的执行动作。等多个流程反复出现同一类授权、恢复或验收需求，再把它提炼成通用服务。

这条路并不排斥基础设施创新。真实业务反而能帮团队看清：哪些是单个客户的定制要求，哪些才是可复用的基础能力。如果每次交付都要重做大量逻辑，产品可能还是一项集成服务，而不是平台。

算账也一样，不能只看 Token 单价或自动化比例。更有意义的口径是：

每个合格完成任务的总成本 = 模型与工具成本 + 基础设施成本 + 人工复核与返工成本 + 预期异常损失

这个口径要求企业先统一验收标准和成本归属，不能凭演示里的速度宣称省了多少人力。一套调用成本更高、但复核更少的系统，可能比便宜却经常返工的方案更划算。

把“完成”变成可检查的事实

Agent OS 最终要回答的，不是“能同时跑多少个 Agent”，而是几件朴素的事：任务有没有真正完成，授权有没有被遵守，失败之后有没有留下可控的状态，负责人看不看得懂、接不接得住。

应用层值得争的是完整任务，不只是更多入口；基础设施层值得补的是可靠执行、授权和验收之间的衔接，不只是更多组件。

模型决定 Agent 能想出什么办法，系统和组织的设计决定这些办法能不能被放心使用。当 Agent 说“完成了”，我们应该能查出它到底完成了什么。这可能才是 Agent OS 最值得投入的一场竞争。

说明与资料

文中提到的服务能力依据各方公开文档整理，未做产品实测，不构成性能、安全或商业效果的背书，具体版本和可用范围以供应商文档及实际验证为准。需求缺口、产品方向和优先级是作者的分析判断。

• Microsoft：Microsoft Agent 365: The control plane for AI agents，https://www.microsoft.com/en-us/microsoft-365/blog/2025/11/18/microsoft-agent-365-the-control-plane-for-ai-agents/
• Anthropic：Effective harnesses for long-running agents，https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents 。文章讨论跨会话交接与验证，示例主要来自编码任务，不能直接当作所有业务领域的实证。
• Temporal：https://temporal.io/ ；LangGraph persistence：https://docs.langchain.com/oss/python/langgraph/persistence
• MCP 规范 2026-07-28 版，授权安全注意事项：https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations ；A2A 协议：https://a2a-protocol.org/latest/
• Composio：https://composio.dev/ ；Browserbase：https://www.browserbase.com/ ；E2B：https://e2b.dev/ ；Mem0：https://mem0.ai/ ；Langfuse：https://langfuse.com/docs
• Salesforce Agentforce：https://www.salesforce.com/agentforce/ ；Dify：https://dify.ai/ ；阿里云百炼应用类型说明：https://helpcdn.aliyun.com/document_detail/2845095.html