组织应该拥有自己的 Agent 基础设施

我越来越倾向于一个判断：未来，一个团队、组织，甚至兴趣小组，自行部署和定制自己的 Agent，会是一件很正常的事。

原因不只是担心数据交给厂商。当 Agent 开始长期参与工作，它的记忆、工具、执行规则和运行方式，也会逐渐成为这个群体工作方式的一部分。人们会希望使用它，也会希望改变它。

这也是我们选择把 Agent Foundation 从 Harness 到 Managed Agent Service 全面开源的出发点：组织应该能够持续塑造自己的工作方式，Agent 基础设施不应成为新的限制。

Personal Agent 带来的第三个问题

我理解的 Personal Agent，是围绕一个人长期积累上下文、执行任务并跟进事务的系统。这里的 Personal 强调持续服务关系，而不只是一个带有人设的聊天窗口。

要实现这样的系统，至少有两类直接的复杂度。

一类是运行能力：记忆如何维护，任务如何长时间执行，进程中断后怎样恢复，等待用户确认时如何保留工作状态。

另一类是安全边界：Agent 可以读取哪些数据，使用谁的身份，执行哪些操作，什么时候必须停下来请求授权。

我更想讨论第三类问题：谁掌控这套系统。

即使一个托管产品足够可靠，也有合理的安全机制，用户仍然可能希望自己保存长期记忆、接入内部工具、修改执行行为，或者把服务迁移到现有基础设施上。可靠性和安全性不能代替这种控制权。

对个人来说，这可能只是偏好。对一个有共同资料、共同事务和自身规则的群体来说，它会影响长期协作。过去做过什么决定、为什么这样做、哪些尝试失败过，这些内容不应该只能存在于某个成员的私人助手里，也不应该只能按照某个厂商预先定义的方式使用。

我期待的扁平，是上下文中的扁平

在之前的 《AI Native 组织思考》 中，我把未来组织想象成一个“超级兴趣小组”：人们因为共同目标聚在一起，通过探索和交流，把个体认知汇入集体工作。

后来在 《零散的想法，无AI》 中，我又把这个问题表述为：当人能够借助 AI 更快地构建和改进工具，组织需要关注的，就不只是如何分配生产任务，还有如何组织集体智商、减少沟通损失。这里讨论的 Agent 基础设施，是对这个想法的一次工程回应。

这里的扁平，不是组织图上少画几层。

一个团队即使没有很多职级，只要每个人仍然只掌握一小块背景、只负责一个固定环节，跨越边界就必须等待别人转述和交接，它的协作方式仍然可能很僵硬。

我期待的是另一种状态：人们能够在授权范围内理解共同目标、过去的决定和当前进展，再根据自己的能力、特长和兴趣参与具体问题。Agent 帮助人跨越一部分执行门槛，工作结果则能够回到共同的工作进程中。

例如，设想一个开源社区准备发布新版本。有人擅长理解用户反馈，有人擅长实现，有人擅长测试和文档。他们不必都从同一份聊天记录里重新拼凑背景：相关 issue、设计决定、已知风险和未完成事项可以形成可追溯的共同资料，各自的 Agent 在权限范围内使用这些资料，贡献者再把结果补回去。

这里需要区分两种尺度的上下文。在 《LLM只是计算，Context才是内存》 中，我用内存和外部存储的类比，讨论了模型实际参与推理的上下文与外部资料的区别。组织层面的共同上下文，则是能够持续维护、按需获取的工作背景；每次执行只取用其中与任务相关、且有权访问的部分。

所以，共同上下文不是把所有信息塞进同一个模型窗口，也不是取消私人空间。它意味着完成工作所需的背景能够被找到、理解和更新，而不必始终依赖某个人充当信息中转站。

我认为，Agent 有机会削弱固定岗位对信息和执行能力的限制，让分工更多围绕问题形成。专业能力、决策责任和冲突协调仍然存在；改变的是人参与工作的边界。

这是一种值得探索的组织方向，而不是技术已经证明的必然结果。即使科层结构没有消失，让人更容易理解问题、跨越边界并做出贡献，本身也值得投入。

Self-host 与 Managed Agent 并不矛盾

在 《聊聊云上Agent的架构设计》 中，我沿着 Chatbot 到执行系统的演进，讨论了消息、环境和运行状态的区别。Agent 开始操作文件、调用外部服务之后，保存聊天记录并不足以恢复一次工作。

如果一个组织决定自己掌控 Agent，接下来就要面对这些实际的运行工作：接收任务、保存状态、分配执行资源、处理等待和中断，以及让成员知道任务究竟进行到了哪里。这些工程问题不应该由每个业务应用重复解决。

我认可 OpenAI Agents API 和 Claude Managed Agents 所代表的产品方向。它们把长期会话、执行环境和运行状态做成服务，应用开发者不必每次从一次模型调用开始，重新搭建整套 Agent 生命周期。

这个需求是合理的。值得讨论的是：这些托管能力必须由外部厂商掌控吗？

一个组织完全可以自行部署服务，由内部平台负责执行、持久化、权限和恢复，再让成员与业务应用使用托管好的 Agent。对使用者来说，它是 Managed Agent；对组织来说，它是 Self-hosted Infrastructure。

大多数成员不需要成为 Agent 运维工程师。组织需要有能力维护自己的服务，成员需要方便地使用它。这两件事可以同时成立。

同样，自行部署也不等于拒绝所有外部服务。组织可以继续选择云模型、外部沙箱或搜索服务，关键在于知道哪些数据会离开自身边界，以及哪些组件可以替换。把 Agent 服务部署在内网，却把工作材料发送给外部模型，显然不等于“数据不出内网”。

要看清可以定制的是哪一层

讨论厂商锁定时，不能把模型、Harness、沙箱和托管服务混成一件事。

这里的 Harness，可以理解为组织模型调用、工具执行、上下文处理及一次运行过程的执行层；Service 则进一步负责把它变成可持续使用的服务，管理资源、任务状态、调度和恢复。

OpenAI 的文档区分了由平台托管 Harness 的 Agents API，以及在自己应用中运行的 Agents SDK。OpenAI 和 Claude Managed Agents 也都提供自托管沙箱选项。因此，使用这些服务，不意味着每一层执行环境都必须由模型厂商提供。

不过，沙箱放在哪里，与谁掌控 Harness、会话状态和托管服务，是不同的问题。可以接入自己的执行环境，并不自动意味着可以修改整套系统。

我更关心的定制边界是：当默认行为不适合组织时，能否继续往下改？是只能调整提示词和工具配置，还是能够修改执行策略、接入现有权限体系、调整状态管理，并维护自己的服务版本？

封闭的托管产品可以有真实价值：减少维护工作，提供集成好的运行环境，让团队更快交付产品。我们没有必要否认这些优势。

我们想提供的是另一种选择：需要托管能力的人，不必因此放弃深入修改系统的可能；需要自主控制的人，也不必从零重新拼装所有基础能力。

定制成本下降后，基础设施应该更容易修改

我选择这条路线，还基于一个判断：随着 Coding Agent 继续降低定制软件的成本，个人和组织会更愿意修改工具，让工具适应自己的工作，而不是始终反过来适应工具。

这也延续了 《AI Coding is a framework, and...》 中的一个提醒：实现门槛降低，不意味着复杂度消失，需求是否清楚、输出是否正确，仍然需要判断。

因此，这里的成本下降，不意味着软件已经不需要维护。需求判断、验证、升级和故障处理仍然需要投入。我的判断是，当实现改动变得更容易时，过去因为成本过高而被放弃的定制需求，会更值得尝试。

例如，一个研究小组可能希望按自己的资料分类维护记忆；一个开发团队可能希望把人工确认接入既有发布流程；一个社区可能希望让 Agent 遵守自己的贡献规则。这些需求未必足够普遍，不一定会进入某个通用产品的路线图，但它们对使用者可能很重要。

因此，我希望 Managed Agent 服务是 hackable 的。这里指的是开发者能够理解、修改、扩展和替换系统，而不只是拥有几个配置开关。

开源不会自动消除维护成本，也不会自动带来良好的可定制性。清晰的边界、可理解的实现和能够验证的行为仍然重要。它提供的是一个前提：当使用者需要继续深入时，不会因为拿不到实现而被迫停下来。

为什么 Agent Foundation 从 Harness 到 Service 一起开源

在 《下一代 Agent Foundation：标准化 Agent 与世界的边界》 中，我把关注点从 Agent loop 移向了它与外部系统的连接：什么时候运行、如何获得上下文、产生什么副作用，以及等待之后如何继续。可定制的 Harness 很重要，把它接入组织既有工作过程的服务边界同样重要。

Agent Foundation 的架构提供两条使用路径：应用可以直接嵌入 Harness，也可以通过 Service 使用托管能力。Service 的 worker 复用同一个 Harness，而不是另建一套执行引擎。

这对应不同程度的接管需求：

• Harness 提供可嵌入的执行能力，通过插件、自定义工具和 Provider 扩展行为。
• Service 在执行能力之上管理资源、权限和持久化运行，承担调度与恢复等托管职责。
• Console、API 和客户端提供管理与使用入口，让人和应用能够接入这套服务。

项目 README提供了 Docker Compose 启动路径，也保留了从源码开发和扩展各个组件的方式。直接使用与深入修改，不应该是两套互不相通的产品。

如果只开放交互界面，使用者仍然无法决定底层行为；如果只开放 Harness，想提供组织级服务的人仍然需要自己建设托管层；如果只提供托管接口，执行逻辑不合适时，用户又会被限制在接口允许的范围内。

这就是我们选择把这几层一起开放的原因。定制需求不应该到提示词或某个 API 的边界就被迫停止。

Agent Foundation 目前仍处于活跃的 0.x 开发阶段，API 和配置可能继续变化。我们提供的是构建和运行 Agent 系统的基础，不是一套已经验证了所有组织协作设想的成品。具体如何组织共同记忆、怎样让贡献进入工作进程、哪些决定应当由人承担，仍然需要在真实场景中探索。

为不同的工作方式保留空间

我不认为所有组织最终都应该运行同一种 Agent，也不认为某个基础设施项目能够替大家决定最佳的组织形态。

我期待的恰恰是相反的方向：个人、团队和社区可以根据自己的目标，逐步形成不同的 Agent 和协作方式。有人使用完整的托管服务，有人维护自己的部署，有人深入修改 Harness，有人围绕已有能力构建产品。

自治也不意味着彼此成为孤岛。在 《Agent 联邦：从云 Agent Foundation 到 Human-Agent Society》 中，我进一步设想了不同管理域保留自身身份、记忆和授权策略，再通过公共契约协作的方向。那是对跨域协作的推演；本文回到更基础的一步：每个群体首先应该能够掌控自己的 Agent 系统。

如果 Agent 会成为长期积累知识、执行事务和开展协作的基础设施，那么人们就应该能够拥有和改变它。

这也是我们开源 Agent Foundation 的理由。我们希望减少每个团队都要重复承担的基础工程，同时把工作方式的决定权留给真正使用它的人。

至于未来的组织会变成什么样，我更愿意通过这些实践去寻找答案，而不是先把答案写进一个封闭产品里。