WorkBuddy正当红，但Agent的未来不在聊天框

最近两年，Codex、Grok、各类 Bot 和 WorkBuddy 式产品迅速崛起。它们有一个共同特点：以 Agent 自身作为入口。 用户打开一个独立应用，发起对话，描述任务，上传文件，授权工具，然后等待 Agent 返回结果。人不再逐步点击菜单，而是直接表达目标；软件也不再只是被动响应，而是开始理解、规划和执行。于是很多人自然会认为，未来的软件世界将由一个又一个 Agent 入口组成。

我的判断不太一样：

独立 Agent 工具会长期存在，却很可能不是未来企业工具的主流形态。未来真正普遍的形态，是 Agentic Capability 嵌入现有系统，在一个具体的 Context 和 View 下工作。

我们不会总是离开工作现场，打开另一个 Agent，再把任务背景重新解释一遍。更多时候，Agent 会直接来到工作现场。

独立 Agent 为什么会让人觉得它就是未来

今天的独立 Agent 产品，有点像个人电脑时代早期的“超级应用”。它们集成模型、对话、文件、浏览器、代码执行和各种工具，在一个入口里展示智能能力的完整上限。这种形态特别适合三类场景：

探索性任务：用户自己都还没有想清楚问题，需要在对话中逐步澄清；
跨系统任务：需要同时查资料、写文档、跑代码、生成内容；
专业工作台：开发、研究、设计等角色需要一个高自由度、强执行能力的环境。

Codex 或 WorkBuddy 这样的产品不会消失。它们会继续成为知识工作者的通用工作台，也是新能力最先被看见、被试验的地方。不过，能力最完整的形态，未必就是使用最频繁的形态。企业的日常任务很少发生在真空中，它们通常依附于一张订单、一份合同、一个客户、一条需求、一段代码、一次故障或一个审批节点。用户一旦需要把这些背景从原系统搬到独立 Agent 中，损失的就不只是几分钟输入时间，还包括大量难以说清楚的上下文。

Agent 的主战场不是聊天框，而是 Context

未来的关键交互单元，可能不是一个 Chat，而是一个 Context / View。销售打开客户页面时，组织关系、历史沟通、商机阶段、合同状态和下一步动作已经摆在眼前；产品经理打开一条需求时，用户反馈、业务目标、关联版本、依赖团队、验收标准和历史讨论也都在当前页面；研发人员进入代码仓库，看到的则是架构约束、代码、测试、脚本、缺陷和发布流水线。这些内容本来就是工作上下文，Agent 在这里不必反复确认“哪个客户”“哪条需求”或“哪个仓库”。

我更愿意把这种形态概括为：

一个 Context / View，一个系统 Agent。

这里的“一个”不是说每个页面都要运行一个独立模型实例，而是说在一个业务上下文中，用户面对的是统一的 Agent 身份。它理解当前对象，继承系统权限，调用这个系统专属的 Skills、脚本和测试，并对自己的行动负责。同一系统里的销售、产品、研发、测试和管理者，也不必各自拥有互不相干的 Agent。大家可以与同一个系统 Agent 对话，角色差异由权限、Skills 和任务契约表达。到了这一步，Agent 才从外部助手变成系统的一部分。

SoE 会成为人与 Agent 的日常入口

在企业架构中，可以把与 Agent 工作有关的系统粗略分成三类。System of Engagement（SoE） 负责人与系统交互，飞书、微信、Slack 和各种业务工作台都可能承担这个角色，人们在这里表达意图、协作、确认并处理例外。System of Context（SoC） 为 Agent 提供当前任务需要的业务语义，包括对象、关系、历史、规则、知识、权限与状态。System of Record（SoR） 则保存企业的权威事实，客户、订单、合同、账户、代码、配置和审计记录，最后仍然要落在可信的记录系统里。

Agentic Capability 不必单独悬浮在三者之外，它可以进入这些系统内部：

在 SoE 中理解意图、维持协作和发起任务；
在 SoC 中检索、推理并组织与当前任务相关的上下文；
在 SoR 中依据权限执行受控动作，并留下可审计记录。

飞书或微信的价值因此不只在于传递消息，它们可能成为一种通用的 System of Engagement。人继续在熟悉的会话和协作界面里工作，背后的系统 Agent 被激活、协同和调度。用户不必知道某一步由哪个模型完成，对他来说，只是工作在继续向前推进。

Agent 不只响应人，也会被事件和其他 Agent 激活

今天，我们习惯把 Agent 当作问答对象：人问，它答；人下命令，它执行。未来的系统 Agent 至少会有三种激活方式。用户可以在当前 View 中主动提出目标，例如“根据这条需求生成验收方案，并检查是否存在跨团队依赖”；客户风险升高、交付延期、测试失败或库存异常等业务事件，也可以触发 Agent 分析并在授权范围内采取行动；上游 Agent 还可以把结构化任务交给下游系统 Agent，由后者在自己的 Context、权限和规则内继续执行。

企业里由此会形成 Agent-to-Agent 的协作网络，但它不能靠几个“万能 Agent”随意聊天来维持。身份、权限、任务契约、运行轨迹、人工审批和失败恢复都必须明确，否则 Agent 越主动，系统风险越大。

为什么嵌入式 Agent 更可能成为主流

嵌入式 Agent 首先减少了上下文搬运。它就在业务对象和流程旁边，知道当前讨论的是什么，也可以沿用系统已有的权限边界，明确哪些数据可读、哪些状态可改、哪些动作必须审批。它的工作也不必停在“给出一段建议”，而可以继续更新状态、触发流程、调用工具、验证结果并留下记录。

这种形态还让智能能力有了稳定的沉淀位置。每个系统都有自己的数据结构、脚本、测试、Skills 和业务规则，这些资产可以与系统一起版本化，而不是散落在个人对话和临时 Prompt 中。只有当 Agent 理解当前状态、受到权限约束并拥有明确触发条件时，主动执行才可能变成一种可靠能力。

OpenAI 正在提供的，也不只是一个聊天入口

这个方向已经可以从技术供给侧看到。OpenAI 的 ChatKit 提供可嵌入前端的 Agent 对话组件，并支持把界面连接到自有服务器上的 Agent 服务；Agents SDK 为应用提供 Agent、工具、handoff、guardrail 和 tracing 等编排能力；更底层的 Responses API 与工具体系，则让应用把模型接入自己的数据、流程和执行环境。OpenAI 提供的已经不只是一个最终用户产品，也包括让其他应用构建和嵌入 Agent 的基础设施。

未来的竞争不只是谁拥有最强的 Agent App，还包括：

谁能让 Agent 更自然地进入真实系统、更准确地获得 Context、更安全地采取行动。

企业真正要建设的，是“系统 Agent”

如果这个判断成立，企业的 AI 路线就不能只停留在采购几个独立 Agent 工具，还要为核心系统逐步建设自己的系统 Agent：

明确它服务的业务 Context 和对象边界；
定义它能够调用的 Skills、工具和脚本；
建立读写权限、行动分级与人工确认机制；
让测试、评测集、运行轨迹和失败案例持续回流；
通过标准契约，让它能够被人、事件和其他 Agent 激活。

未来系统的交付物也就不再只是功能和界面，还包括一套与系统共同演进的智能能力：Context、Skills、Tools、Policy、Evals 和 Traces。

结语：Agent 会从工具变成系统的一种属性

今天我们谈论 Agent，有点像早期互联网时代谈论“上网软件”。智能能力还稀缺、产品边界也清晰，所以它首先以独立产品的方式出现。当这些能力逐渐标准化、基础设施化，用户对“另一个工具”的感知会越来越弱，Agent 则会成为各类系统的默认能力。

人们仍然会使用 Codex、Grok、Bot 和 WorkBuddy，但更多日常工作会留在原来的业务现场：一条消息里、一张卡片上、一个客户页面中、一个代码仓库内。那里的 Agent 知道用户正在处理什么，知道自己可以做什么，也知道何时应该停下来请求确认。未来的软件不会被 Agent 全部替代。

未来的软件，会普遍拥有 Agent。