观察基线：2026 年 8 月 20 日

本文不是六款 Agent 产品的完整测评，也不代表六个样本能够覆盖整个 Agent 市场。文中的 Workspace、Context、Work Loop、Governance、Responsibility Boundary 是本文采用的一组产品架构观察维度，用于讨论 Agent 如何进入持续工作，不代表相关厂商对自身产品的官方架构定义。

本文不是一篇 Tool Calling 教程，也不是六款产品的功能排行。它讨论的是一个更偏产品架构的问题：当 Agent 已经能够调用工具、执行动作以后，系统还需要补齐哪些责任，才可能从一次任务执行进入持续工作？

Tool Calling 解决的是 Agent 如何把模型判断转化为外部动作，但它并不自动解决工作承载、上下文连续性、运行推进、治理和责任边界。对产品经理、架构师和 Agent 开发者来说，这些问题才决定 Agent 能否进一步进入真实工作的持续运行。

问答 AI 主要回答问题、生成内容，Agent 则开始围绕目标组织步骤、使用工具并执行动作。这个差异仍然重要：一个主要停在答案，另一个开始把事情往前推。

但当 Agent 真正进入产品设计和工程实现，判断标准就不能只停在“它能调用多少工具”。还需要继续追问：工作由什么承载，上下文怎样延续，一轮执行结束后为什么还会有下一轮，行动受到什么约束，以及什么可以交给 AI、什么必须由人负责。

这个区别当然还在，只是市场已经继续往前走了。有的 Agent 已经能够围绕真实任务在后台推进，有的可以按照时间或外部事件重新启动，还有的平台开始处理跨 Session 的状态、长期记忆和更长时间的运行。GitHub Copilot cloud agent、Microsoft Copilot Studio、Tencent WorkBuddy、Claude Code、ChatGPT Work、Gemini Enterprise Agent Platform 虽然形态不同，但都让同一个问题变得越来越具体：当 Agent 已经越来越能执行任务，我们还应该用什么来判断它是否正在进入真实工作的持续运行？

这篇文章不是六款产品的排行榜，我也不准备判断谁“更 AI Native”。我更关心的是，把这些不同形态的产品放在一起，会反复遇到哪些工作系统问题。

对产品经理、架构师和开发者而言，这些问题比“又多了一个 Agent 功能”更值得关注，因为它们最终都会落到产品对象、状态设计、权限、协作和运行机制上。

六类 Agent 产品观察地图

一、Workspace：Agent 开始工作以后，工作到底落在哪里？

一次问答很容易理解。打开窗口，提出问题，AI 给出答案，即使中间调用了几个工具，这次任务也可能随着对话结束而结束。

真实工作却很少这么干净。

软件开发就是一个很直观的例子。GitHub Copilot cloud agent 可以围绕代码库、Issue、Branch 和 Pull Request 推进开发任务。把一个 Issue 分配给 Copilot 时，它会创建 Pull Request；如果从 Prompt 启动任务，则默认先在 Branch 上研究、规划和修改，用户可以查看结果、继续调整和迭代，再决定何时创建 Pull Request。

这里真正有意思的不是“Agent 会写代码”，而是它的工作开始落在一组真实、持续存在的工程对象上。代码库还在那里，Issue 有自己的状态，Branch 保存修改，Pull Request 承载后续 Review。Agent 做了什么、人从哪里接手、下一次修改从哪里继续，不再只存在于聊天记录里。

WorkBuddy 是另一种形态。当前产品允许任务指定工作空间，Agent 可以基于相应目录读取和处理文件，已有任务也能够继续在原有上下文上处理；到了团队协作层，“项目”又通过项目与任务两层结构共享上下文、标准和知识。

当然，GitHub 的 Repository、Issue 和 Pull Request 不能直接等同于本文所讨论的 Workspace 架构概念，WorkBuddy 产品里叫“工作空间”的对象也不能因为名字相同，就直接等同于同一架构定义。产品机制和本文采用的观察维度是两件事。

但这些产品都在逼近同一个现实问题：Agent 一旦真正进入工作，这项工作由什么持续承载？

一个 Agent 可以很聪明，也可以有很多工具，可如果每次运行都像重新打开一张白纸，人仍然要承担工作连续性的主要责任。真正进入工作以后，系统需要知道自己正在处理什么，人也需要知道工作现在到了哪里。

所以我现在看一个 Agent，已经不会只问它有什么工具。我还会看：这项工作究竟落在哪里。

二、Context：任务一旦变长，上下文就不只是 Prompt 的问题

工作的承载对象明确以后，第二个问题很快就会出现：Agent 怎样持续知道自己现在正在做什么。

短任务里，这件事不明显。问题、资料和刚刚发生的对话大多还在当前窗口中，模型只要把眼前的信息处理好就够了。

但如果一项工作持续几个小时、几天，甚至跨过多个 Session，情况就完全不同了。

Claude Code 已经通过 Session、项目环境和跨会话记忆等机制，支撑软件工程 Agent 在较长任务中的上下文延续。构建方式、调试经验、项目约定和部分工作信息可以被后续 Session 使用。Gemini Enterprise Agent Platform 则把 Session 与 Memory Bank 分成不同机制，让当前交互状态和跨 Session 的长期信息承担不同职责。WorkBuddy 的任务和项目也呈现出类似的问题意识：单项任务需要自己的上下文，更上层的项目又需要共享团队知识和工作背景。

这些机制当然不能直接等同于我们所说的 Context Architecture 或 Memory Architecture，但它们都说明：任务一旦变长，上下文就不再只是“Prompt 写得好不好”。

系统需要知道当前工作状态，上一步产生的新信息要能够进入下一步，目标发生变化以后，Agent 对当前工作的理解也必须随之调整。如果这些信息在推进过程中不断丢失，再强的模型也只能在每一步重新猜测，人还是得不停解释“刚才做到哪里”“哪些情况已经变了”“现在真正应该处理什么”。

于是，Context 开始从一次模型输入的问题，变成工作能否连续推进的问题。

三、Work Loop：这一轮执行完以后，下一轮为什么发生？

这是我认为今天观察 Agent 最值得注意的一层变化。

早期看 Agent，我们很容易关注它一次能连续执行多少步。五步、十步、二十步，规划之后再逐项调用工具，本身就足够令人印象深刻。

但“多步骤执行”主要解决的是这一轮任务能不能连续做完。真实工作的连续性还要再往后问一步：这一轮结束以后，下一轮为什么发生？

现在的产品已经出现了几种不同的做法。

一种是按时间或计划重新运行。据 OpenAI 当前公开资料，ChatGPT Work 的 Scheduled Tasks 可以让任务运行一次、按照既定计划或事件重复执行，也可以持续监控随时间发生的变化。WorkBuddy 的自动化能力同样可以按照设定计划再次启动任务。这里已经不是用户每次都重新打开聊天窗口，再说一句“继续”。

另一种是由业务事件重新触发。Microsoft Copilot Studio 的 Agent Flow 可以由计划或外部事件触发；GitHub Copilot cloud agent 也可以结合 repository event 或 schedule 发起后台任务。工作的下一轮开始与系统里真正发生的事情建立了联系。

还有一种更直接：平台开始处理更长周期的运行。Google 当前的 Gemini Enterprise Agent Platform 已经把 long-running job 做成 Agent Runtime 的显式能力，官方公开范围最长可达 7 天。这类机制让“Agent 一次到底能运行多久”从一次演示效果变成了 Runtime 设计问题。

软件开发场景还提供了另一种很典型的连续性。一次代码修改并不意味着工作完成，后面还可能有 Pull Request、测试失败、Review 意见和新的修改。执行结果本身会成为下一轮工作的输入。

这些机制并不等于我们定义的 Work Loop。定时执行也好，事件触发也好，长时间运行也好，都不能因为“能继续跑”就自动证明一个完整的持续工作系统已经成立。

真正困难的是，下一轮为什么发生、继承什么状态，失败以后怎样恢复，外部情况变化后是否需要重新判断，以及工作在什么条件下继续、等待或者结束。

能执行任务，并不自动等于能持续工作。

这句话不是在否定今天的 Agent。恰恰相反，正因为 Agent 已经越来越能执行，我们才终于需要认真讨论执行之后的事情：工作怎么继续。

四、Governance：Agent 越能行动，权限和治理越不能后补

当 AI 只是生成一段建议时，我们最容易担心的是答案对不对。一旦 Agent 开始真正修改文件、运行命令、调用企业系统或者对外采取行动，产品设计面对的问题就变了。

Claude Code 已经有细粒度 Permission 体系，可以决定哪些工具动作允许直接执行、哪些需要询问、哪些直接禁止。GitHub Copilot cloud agent 完成代码修改以后，工作仍然进入 Pull Request 等已有审查机制，高权限 Workflow 也保留人工批准边界。WorkBuddy 把工作空间作为当前任务主要文件操作边界，对敏感操作设置权限控制。Microsoft Copilot Studio 则把 Agent、Workflow、Trigger、Tool 与企业级数据策略放在同一个产品体系里。

几家产品的实现方法并不一样，也没必要硬凑成一种模式。但从这些样本可以看到一个很稳定的现象：Agent 越能行动，权限、身份、审批和审计就越靠近产品核心。

治理因此不是“先把 Agent 做强，以后再补一个后台权限页面”。如果 Agent 真要进入生产环境，系统必须从一开始就回答它能访问什么、可以执行什么、什么动作要重新征得人的同意，以及出了问题以后能不能追溯。

所以，当我们说“Agent 开始参与工作推进”时，必须保留一个限定：它只能在被允许的信息、工具和动作范围内参与工作。

少了这句话，“Agent 能执行”很容易被误读成“Agent 什么都可以替人执行”。

五、Responsibility Boundary：能执行，不等于有权决定

这是“全自动 Agent”叙事里最容易被忽略的一面。

如果一个 Agent 能自己规划、调用工具和执行动作，直觉上似乎意味着人应该越来越少出现。但从现在这些产品的设计看，实际情况并没有这么简单。

ChatGPT Work 仍然允许用户在执行过程中查看进度、补充信息、改变方向并批准重要动作。Copilot cloud agent 做完开发工作以后，人依然要 Review 结果，Pull Request 和最终合并仍在已有责任体系中。Microsoft Copilot Studio 在高影响动作上同样强调 Human Review。

这些设计并不是 Agent “还不够强”的临时补丁。它们指向的是另一个问题：一个系统即使有能力执行某项动作，也仍然需要回答谁有权决定这项动作此时应该发生。

Agent 越能执行，系统越需要明确什么可以交给 AI，什么必须由人负责。

这就是责任边界（Responsibility Boundary）的问题。

Capability 和 Authority 不能混为一谈。Agent 有能力修改数据，不等于它天然有权决定现在应该修改；有能力发送信息，也不等于它可以代表组织作出外部承诺。付款、审批、敏感数据、对外发布和不可逆操作尤其如此。

人的角色未必还像过去一样负责每一步操作，但责任并不会随着操作自动化一起消失。真正成熟的人机协同，反而需要把这个边界设计得更清楚。

看 Agent，不妨多问这五个问题

六、一个更实用的 Agent 五问框架

把这六个样本放在一起，只用“它能做哪些事情”来描述一个 Agent 已经不够。对产品经理、架构师和 Agent 开发者来说，能力清单只是起点。

“能做什么”当然重要，但它主要告诉我们能力边界。一个 Agent 真正进入工作以后，还需要观察五件事：

1. 工作落在哪里？

2. 系统知不知道自己在做什么？

3. 下一轮为什么发生？

4. 行动怎么被约束？

5. 什么可以交给 AI，什么必须由人负责？

对应到本文采用的观察框架，就是 Workspace、Context、Work Loop、Governance 和 Responsibility Boundary。这里不用先记英文，先记住这五个中文问题就够了。

它们不是“Agent 五项认证标准”，更不是说五项看起来都有，就可以给一个产品盖章“这才是真正的 AI Native”。这组问题的作用，只是让我们把注意力从“Agent 会多少动作”，慢慢转到“Agent 怎样进入真实工作”。

七、从 Tool Calling 到持续工作：产品架构还需要补齐什么

如果回到前几年，我们很容易用一句话概括 Agent 的变化：AI 不只会回答，它开始会行动。

今天这句话依然成立，但已经不足以解释我们正在看到的产品。

从这六个样本看，Agent 产品的设计关注点已经不再只有“模型能不能把这件事做出来”。任务怎样被承载，上下文怎样延续，工作怎样被重新触发，Agent 怎样运行更长时间，权限怎样约束行动，什么可以交给 AI、什么必须由人负责，这些问题正在越来越多地进入产品设计。

这里必须保持一个边界：六个样本不能代表整个 Agent 市场，更不能证明所有产品都在沿着同一条路线演进。不同产品完全可能形成不同的工作方式和技术路径。

但至少，这些样本让一个问题越来越值得追问：Agent 从“能执行”走向“持续工作”时，产品架构究竟还需要承担哪些责任？

以后再看到一个很惊艳的 Agent Demo，我还是会关心它用了什么模型、能调哪些工具，但不会停在那里。我会再往后看：这项工作由什么承载，状态是否能够延续，下一轮为什么发生，出了问题以后怎样处理，它能行动到什么边界，最后又是谁负责。

因为 Agent 真正进入工作以后，我们讨论的就不再只是一次模型能力有多强，而是：

Agent 怎样工作，怎样继续工作，又怎样在明确边界内工作。

到了这里，才真正开始从一次能力调用，走向真实工作的持续运行。

从“能执行”到“持续工作”

观察边界与说明

本文不是六款 Agent 产品的完整测评，也不代表六个样本能够覆盖整个 Agent 市场。文中的 Workspace、Context、Work Loop、Governance、Responsibility Boundary 是本文采用的一组产品架构观察维度，用于讨论 Agent 如何进入持续工作，不代表相关厂商对自身产品的官方架构定义。

文中涉及的产品名称、功能与状态，以 2026 年 8 月 20 日可核验的官方公开资料为本轮观察基线。Agent 产品仍在快速变化，正式发布后如产品发生重大版本变化，后续观察应重新核验，不沿用本文事实状态作为永久结论。

参考资料

以下均为本文事实核验所使用的官方公开资料，产品状态以 2026 年 8 月 20 日为本轮观察基线：

1. OpenAI：ChatGPT for your most ambitious work；Scheduled Tasks in ChatGPT

2. Anthropic：Claude Code Overview；Memory；Settings

3. GitHub：About Copilot cloud agent；Cloud agent how-to

4. Microsoft：Copilot Studio；Agent flows；Event triggers

5. Tencent WorkBuddy 官方文档：Task Management；Project；Permission Modes

6. Google Cloud：Gemini Enterprise Agent Platform；Release Notes