Agent Platform 的设计思考

English version: Thoughts on Designing an Agent Platform

Background

市面上的 Agent Platform 如 Hermes、OpenClaw、CodeBuddy、CatPaw，几乎都长得一样：MCP、Channel、Skill、Job 等等。

当我们要开发一个自主的 Agent Platform 时，很难逃脱这套设计的枷锁。

但是对于 2B 的企业 Agent Platform，排除刚刚列举的那些部分，能够有差异化的部分我觉得可以是以下几点：

1. 行业垂直产品的集成能力
2. 具备行业垂直知识库
3. 绑定用户累计使用的记忆
4. 具备企业治理能力
5. 自迭代（任务级别）
6. 云端协同

1～3 都是显而易见，且高度依赖数据和领域知识。

但是同时具备企业治理、自迭代、云端协同等能力的 Agent 平台，市面上几乎没有。

简单地说

如何解决 Agent 的权限和角色问题？（企业治理）

详见下文《观点 2：权限都应以 Auth Token 的形式交付》。

现在绝大多数的 Agent Platform 都只支持配置单一角色的 tools。

通过文件系统交付完整的 Agent，借助 Auth Token 和容器变量，实现每个 Agent 都有 Least Privilege 的权限。

通过定制化的 Pi Agent 框架，或者 gateway 可实现 Agent 执行记录管理。

如何实现自迭代

详见下文《第三步：自省》。

借助 A2A 让 Builder Agent 与 Runtime Agent 协作，把每次运行过程中出现的问题，都总结成优化点。通过一定的流程管理来不断迭代现有 Agent。

云端协同的价值

详见下文《第二步：启动沙箱》。

在 2B 场景里，企业主可以要求公司员工安装具备一定自主性的 Local Agent，当某个云端执行 Agent 遇到权限不足的问题时，需要员工在本地授权，并找到对应的授权信息，比如浏览器 session，比如授权后的 token，并发送至云端侧的 Agent。

什么样的 Agent 适合运行在 Agent Platform 上？

稳定、重复执行的工作流 Agent

• 某企业有一个长期稳定运行的业务，比如上架某商品，需要从特定数据源拉取数据，经过图片处理、翻译、填充表单提交审核等流程。
• 某岗位的日常工作，如审批表格数据、提交企业内部表单等高度标准化的岗位，如会计。

数据收集、整理、轻分析和轻决策的 Agent

某企业每日需分析各种销售数据，提供报表和轻度分析总结，给出业务优化建议，Agent 参与决策建议，而非直接执行报表决策。

AI native 岗位的工作

无现有工作流，直接端到端「问题 → 答案」的工作场景。

假设

抛开常规后台系统设计的惯性思维，Agent Platform 是否可以抛弃一些目前看似“必不可少”的行业惯例？

用户至上 VS Agent 至上

我们在传统的后台软件设计里，常常出于用户（人）可读、可操作的目的，设计了复杂的 UI 交互，如前端的字段联动、各种搜索表单和拖拽流程图等。这样做，确实提高了平台数据管理的严谨程度，但是“人可读”这件事大大限制了 Agent 创建的速度，增加了 Agent 设计的复杂度。

观点 1：大量当前软件开发的设计，若不是 Agent 必须的，都可以摒弃。

就 UI 而言，UI 也就是所有与用户交互的部分，应被抽离出 Agent 之外，Agent 的运行能够完全独立于 UI 而存在。换句话说，当我 build 一个 Agent 的时候，我们要尽量与当前后台的所有元素解耦，后台只提供对数据的展示。

“人可读”这件事，在 Agent 时代是伪需求，某个工作只要能够在 build 之后稳定执行，完全可以抛弃复杂的“人可读”的开发工作。比如说，工作流的定义，我们可以用文本描述输入输出，抛弃所有流程图绘制工具。我们可以转而用文本描述流程图，或者利用基于文本的流程渲染工具，比如 mermaid 来与 Agent 沟通。或者利用 AGUI 让 Agent 来对文本做可读性渲染。

流程图只是一个例子，还有许多看似必须的后台配置流程，都应如此，比如注册 MCP、管理记忆、配置访问数据等等。

明确的 Agent Scope

实际上，并不是所有任务都适合使用 Agent 来完成，但是随着模型的发展，Agent 确实已经开始能够胜任绝大多数重复和轻决策的任务。若要让 Agent 符合用户预期，我们应谨慎地识别用户场景，在合适的场景来定义 Agent，并且不断地探索 Agent 的边界，逐渐拓展。

用户的期待管理、Agent scope 的定义，与 Agent 开发本身同样重要。

从能力层面对 Agent 的抽象

当我们要开发一个 Agent Platform 的时候，我们要放弃经典的记忆层、tool 层、模型层的 Agent 抽象方案，转而去凝视 Agent 在运行过程中需要什么？

LLM Access

不做赘述，需要 highlight 的是，build 出的 Agent 应该具备调度不同 LLM 的能力。

File System Access

Agent 配置、SubAgent 配置、记忆、prompt、代码、数据、Skill，都可以被放在文件夹里，成为某个 Agent 的全部集合。

Code Execution

代码就是语言，同样在严谨地用文字描述业务。

用户有许多自定义的流程规则，用户关心 Agent 是否严格按照自己定义的过程来执行。

Computer Use

许多集成能力没那么强的系统，最直接简单的方案就是 computer use，当然这里也包括了 browser use、CLI。

Data Access、Web Access 的陷阱

Data Access、Web Access 的访问应该被涵盖在 code execution 里，我可以允许我的 Agent 通过写 shell 脚本，或者 Python 代码来访问数据，而非直接给数据。

有人要问，如此这般，我要如何控制 Agent 的权限？关于这一点，我会在 Agent 治理的部分细谈。

观点

场景 1：工程师 A 在本地将 Agent 调试到一个理想的状态之后，他想分享他的 Agent 给团队里的所有用户，他即使发送了自己所有定义的 Agent 配置信息和 skill 给团队成员，团队成员依然难以迅速上手此 Agent。

场景 2：某个在云端以用户 A 的角色运行得很稳定的 Agent，有一天需要以用户 B 的角色来执行时，我们几乎难以基于用户 B 的角色迅速复制一个新的环境和新的 Agent。

场景 3：某个 Agent 第一次运行符合预期，当第二次运行时，由于某些变量发生了变化，比如数据、触发条件、时间、模型等，最后产生了不同的结果。

观点 1：一个完整的可交付的 Agent 是一个一切皆文件的 Agent

参考 Linux 的设计哲学「一切皆文件（Everything is a file）」，我认为，当我说交付一个 Agent 的时候，我交付的是一个文件夹里的文件，这些文件的总和，能够完整地定义一个 Agent。

对应于场景 1，我们能很简单地分享、传递、迭代一个 Agent，并且在不同的执行环境里，都能执行它。

观点 2：权限都应以 Auth Token 的形式交付

Auth Token 作为一个字符串，能够被交付和配置在 Agent 的文件系统中；而任何需要登录交互的授权方式，都难以交付给 Agent。这是解决 Agent 授权的关键。

除非我们实现一套完整的授权自动化，能够把文件里的配置交付到 Agent Runtime，那么我们才能支持各式各样的授权方式。

对应于场景 2，现在执行的权限被作为一个环境变量管理，所有的 tool 都能够得以识别当前用户的身份信息。

观点 3：应复用软件工程实践，解决业务问题，提高 Agent 可靠程度

详见下文《Agent Builder Agent 的产物》。

可将 Coding Agent 的所有实践，都应用于业务 Agent Platform 的实现，如引入 Agent Evaluation Framework，引入 UT、Pipeline、CheckStyle、Spec driven 等手段，让 Agent Builder Agent 的产物可靠且可被验证。

Build 一个 Agent

Agent Builder 的角色定义

长远看，Builder 最终必定是某个业务场景的业务专家，他在 build 一个 Agent 时，只是在与模型交互，把脑中的业务场景描述出来，最后形成解决某个问题的 Agent Team。他有垂直领域的知识，但不一定有互联网、软件开发的工作经验。他对流程非常熟悉，但他不一定有对 Agent 犯错的耐受。他知道每个业务的关键节点，但是他不具备 Agent 调试的能力。这一切关于软件工程方面的工作，都应该由模型来覆盖。两点 highlight 需要行业人才的工作经验积累来逐渐补足：

• 程序设计的逻辑思维能力
• 调试一个程序运行的经验

但是在某个企业 Agent Platform 推广初期，我建议 Agent Builder 应有两个互补的人来补全，两人以调试 Agent Builder Agent 的目标协同工作。

1. 具备一定技术背景，但缺少业务深度的人
2. 深度了解业务，但缺乏一定技术背景的人

Build 一个 Agent 的过程

第一步：描述问题，定义目标

Builder 在具备一定经验的前提下，能够清晰地描述问题，能够清晰地定义目标。模型在经过一定程度的发展之后，能够很好地理解用户的诉求，根据所拥有的资源池，给出合适的执行方案。

这个过程的输出应该是非常简洁的、逻辑清晰的流程描述，或者流程图。Builder 和 Agent 持续沟通，直到双方满意为止。

Agent Platform 应有一系列的预设 Agent，能够在 Builder 与 Agent 沟通过程中直接匹配用户的诉求，比如 Deep Research、Data Analysis 或者其它行业里常用的 Agent。

第二步：定义 Agent 的执行方案

这一步应高度结合业务知识，给出合理的解决问题的方案。

第三步：定义 Agent 所能访问的资源

Agent 根据所提出的方案，配置资源访问权限，比如某一个 Agent 需要 Git 提交的权限，我们应要求 Builder 在这里配置 Git MCP 或者 Git code execution，或者 CLI（computer use）。

注：CLI 并非一个理想的解决方案，因为它的授权总是需要一定的交互，除非我们有从当前文件系统交付到 runtime 的自动化的方案。

配置过程中的交互，都应该是 AGUI，按需生成的页面。

生成的 Agent 全部以文件的形式存储在文件系统里。这里仅包含所需授权信息的清单，并不包含任何授权信息（token）。创建 Agent 过程的 session 也同样重要，也会保留在文件系统中。

第四步：定义 Success Conditions / Exit Conditions

系统应默认给每一个 Agent 都强制设定最低限度的 Exit Condition。用户根据业务诉求设置成功的条件。

第五步：调试 Agent

在非沙箱环境中，Agent Builder Agent 对定义的 Agent 进行预执行，用户在安全的 QA 环境进行 Agent 调试。如本地 coding 一般，将流程跑通，并持续与 Builder 沟通。

Agent 更新与管理

若用户对这个 Agent 有任何更新，能够直接延续 Agent 创建过程的 Session，也能继承所有的记忆。

Agent 以一个文件夹一个文件夹的形式存在系统里。用户若有可视化的诉求，可以通过 AGUI 的形式交互。

所有在 Agent Platform UI 层级的开发工作，比如授权的流程，比如 skill 安装等，都不应影响 Agent Builder Agent 的工作，也不应该影响现有 Agent 的运行，比如 MCP 的集成方式。

Agent 执行

Agent 执行环境

Agent 的执行环境必须是一个隔离的沙箱环境，所有的能力通过所赋予的权限清单和 Token 来实现。

Agent 执行步骤

第一步：Trigger

用户通过 Agent UI，或者 job 触发 Agent。

第二步：启动沙箱

触发沙箱启动 pipeline，根据用户信息，检索系统现有 Token，作为启动沙箱的环境变量。

将 Agent 文件夹拷贝至运行环境，若有需要，安装各种依赖。

梳理 Agent 运行所需要的所有资源，若缺少某些信息，触发 Webhook，直接与用户的 Slack 进行沟通（或者与用户的 Local Agent 沟通，此即云 + 端协同）。

第三步：自省

若执行过程中，沙箱里的 Agent 有对自我的修正，触发一个审核通知，允许 Builder review 并将优化后的 Agent 文件合入原始文件中。

第四步：关闭沙箱

根据沙箱定义的层级来清理沙箱：如果沙箱是用户层级，则在用户休眠一段时间后清理；如果沙箱是 session 级别，则在任务结束后销毁。

Agent Builder Agent

为了能够让 build 出来的 Agent 解决实际的业务问题，能够符合企业级的要求，我们应尝试复用软件工程实践，解决业务问题，提高 Agent 可靠程度。

Agent Builder Agent 的产物

我认为，Agent Builder Agent 的产物应是一个构建在代码之上的 Agent。可利用现成成熟、流行的 Agent SDK，比如 Pi Agent、Claude Agent SDK、LangChain。

我认为，为了保证 Agent 执行的结果可信、可重复、可被验证，Agent Builder Agent 所 build 出的产物包括任何能帮助我们保证它的质量的东西：

1. 业务代码
2. skill
3. pipeline
4. prompt
5. shell 脚本
6. ……

它能够：

• 运行在沙箱里
• 自主编排流程
• 在运行过程中，所有授权信息以环境变量来体现

Agent Builder Agent 是什么？

我认为 Agent Builder Agent 就是一个能力很强的 coding agent：

• 它被定义去构建一个 Agent
• 它能够访问一个资源池，它知道自己所有的能力
• 它有一个软件框架，软件框架要求它对 Agent 进行自主的填充，填充的内容来自于资源池
• 它被定义了一套编程规范、自我验证的规范

资源池的定义

资源池是 Agent 所需数据集合的抽象，它被抽象成：

• 类型：mcp

  skill

  tool

  llm

  memory

• Description
• Permission
• Verification

软件框架定义了什么？

所有被抽象出来的流程，都可以定义在框架内，比如校验权限流程、索取权限流程、Agent 自我迭代的流程等。

核心观点

1. 被交付的 Agent 要能够完整地在文件中被表达
2. Agent Platform 的核心功能在于 build agent 的 agent
3. 企业治理、自迭代、云端协同等差异化能力是开发一个自主 Agent 平台的主要动机
4. 若要 build 一个符合企业标准的 Agent，需要尽量恰当地运用软件工程实践，将 Agent 构建在软件工程之上
5. AGUI 应该替代传统的后台管理页面，成为主要与用户交互的方式