解决什么问题

当前市面上的Agent产品分三类，各有明确的局限。

单体Agent工具（Claude Code、OpenCode、Cursor）：解决"一个人用一个Agent干活"的问题。但企业场景需要多个Agent协作，这类工具没有标准方式让Agent A调用Agent B。

Agent协作平台（Multica、Loop）：解决了"多个Agent在一个系统里协作"的问题，但协作范围限定在自系统内部。Loop的Orchestrator只能调度注册在Loop里的Subagent，Multica的Actor模型只能管理Multica平台内的Agent，它们没有跨平台的Agent发现和协作协议。现实中企业用不同平台是常态。

自主执行Agent（Manus）：给用户一个目标，在云端虚拟机上自主规划执行。但它是封闭系统：执行过程黑盒、单Agent架构、云端锁定、无开放协议。

我们要解决的具体问题：

1. 用户怎么开箱即用Agent。不是让用户自己配置Agent，而是开发者用工厂平台构建好Agent，用户直接用。OpenCode需要写SKILL.md，Loop需要理解20多种角色定义，这是开发者工具的问题，不应该让终端用户承担。
2. 本地Agent怎么调用云端能力。OpenCode跑在本地的Agent，想调用企业知识库或高级模型，没有标准路径。
3. 跨平台的Agent怎么互相发现和对讲。A厂商的客服Agent需要调用B厂商的库存Agent，两个Agent跑在不同平台上，没有通用协议。Google的A2A协议定义了通信格式，但没有定义注册、认证、撮合、治理。

1.2 不做的事

• 不做基础模型。调用Claude/GPT/DeepSeek等现有模型。
• 不替代现有工具。OpenCode和Claude Code继续用，工厂负责管理和编排。

1.3 竞品启示

产品	设计启示	我们要避免的
OpenCode	技能按需加载（不全塞上下文）、权限用glob pattern、配置即文件。三个决策让Agent配置变成项目文件编辑	纯本地无云编排、技能全量加载浪费上下文、配置门槛让终端用户无法直接使用
Loop	扁平单层协作（Subagent互不调用）+ 文件系统做共享记忆协议 + 停滞检测看重复错误模式而非超时	强绑定TiDB、闭源、20多种角色定义过重
Multica	Agent和Human用同一套数据模型（多态Actor），任务队列+信号量控制并发	重项目管理轻Agent构建
Manus	Planner-Executor-Verifier三阶段 + 沙箱隔离 + 执行快照可回滚，解决自主执行失控问题	黑盒、封闭、云端锁定、无开放协议
OpenClaw	聊天应用做Agent入口Gateway + Markdown文件持久化记忆（透明可编辑）+ Pi SDK分层组合	绑定聊天应用交互受限、无Agent间协作协议
Hermes	自改进循环（任务→评估→提取技能→入库），Agent越用越强。方向对但要加人工审核	技能提取全自动不可控、可能积累垃圾技能
Pi（pi.dev）	极简核心（4工具）+ 自我扩展（Agent自己写扩展热重载）。会话即树（分支回溯不浪费上下文）。分层monorepo每层独立可用	无子Agent、无网络协作、终端限定
A2A协议	Agent Card和Task Lifecycle是事实标准，直接在此基础上做撮合和治理	只管通信格式，不管注册发现、撮合、信任、仲裁

跨平台Agent协作是空白地带。Google的A2A协议定义了通信格式但没有撮合和治理，这是A2A网络平台的核心差异。

二、Agent工厂平台

Agent工厂平台是开发者构建和运行Agent的基座。开发者用工厂平台定义Agent的角色、技能、工具、记忆，构建好的Agent以模板形式发布，终端用户直接选用，开箱即用。工厂平台同时也提供Agent的运行时环境（本地、云端、混合），以及开发者工具（CLI、SDK、IDE插件）。

2.1 Agent定义模型

Agent的核心数据结构采用YAML格式，包含以下模块：

• 元数据：ID、名称、版本、归属、标签
• 角色定义（Persona）：角色类型、语气、专业领域、约束条件
• 执行模式：工作流编排（step-by-step）或目标驱动自主（autonomous）
• 记忆配置：持久化策略、存储位置、保留时长
• 技能清单：引用的外部能力（MCP Server、内联代码等）
• 工具清单：Agent可直接调用的工具集（含权限和沙箱限制）
• 模型路由：默认模型、条件路由、降级策略
• 触发器：Webhook、定时任务、A2A调用
• 运行时配置：本地/云端/混合、资源配额、沙箱策略

关键设计决策：

1. 格式采用YAML：可读性优先，配置即代码。
2. 继承OpenCode的SKILL.md规范：兼容现有生态。
3. 模型路由独立配置：不硬编码模型选择，支持按条件自动切换。
4. 运行时类型显式声明：local/cloud/hybrid三种模式，影响调度策略。

2.2 两种执行模式

2.2.1 工作流编排

适用场景：流程确定、需要精确控制、重复性任务。

核心特征：用户用可视化画布定义固定的执行路径，每个节点行为确定，画布是有向无环图（DAG），支持并行分支。

与Dify的关键差异：节点可嵌入自主执行子Agent（混合模式），执行路径完全透明可审计，支持A2A协议可被外部系统调用。

2.2.2 目标驱动自主

适用场景：目标明确但路径不确定、需要灵活决策、一次性复杂任务。

核心特征：用户描述目标，Agent自主规划执行路径，执行中可动态创建子任务、选择工具、调整策略。采用Planner-Execution-Verification架构。

与Manus的关键差异：

维度	Manus	我们的实现
执行环境	云端虚拟机（黑盒）	本地沙箱或云端容器（透明）
工具集	固定内置	用户可配置，支持MCP扩展
干预能力	只能暂停/重试	可实时修改约束、增减工具
复用性	单次任务	保存为可复用的Agent模板
协作	无	支持A2A，可被其他Agent调用

2.2.3 模式选择

场景特征	推荐模式	理由
流程固定、重复执行	工作流编排	确定性高，成本低，易维护
目标明确、路径不确定	目标驱动自主	灵活性强，减少人工拆解
跨多个系统操作	混合使用	工作流定义主流程，自主节点处理复杂子任务

模式在Agent级别声明。混合使用时，工作流画布中可嵌入自主执行节点。

2.3 Agent构建方式

面向开发者，提供四种构建途径。

从模板创建：浏览模板市场 → 选择模板 → 修改参数和配置 → 系统生成Agent定义 → 本地测试 → 发布到模板市场供用户使用。官方模板库Phase 1目标20个，覆盖开发、数据、运营、个人四大类。

从自然语言创建：用自然语言描述Agent的能力和行为 → LLM解析意图 → 生成候选Agent定义（YAML）→ 开发者审核和调整 → 确认后可用。降低开发者从零开始写配置的成本。

从现有配置导入：支持OpenCode SKILL.md、Dify工作流JSON、LangChain代码、CrewAI配置、自定义YAML/JSON。导入后做兼容性检查，生成报告。方便从其他平台迁移。

从空白创建：完整的YAML编辑器，支持语法高亮、自动补全、Schema验证、版本对比。适合需要完全自定义的高级开发者。

构建完成的Agent以模板形式发布到市场，终端用户浏览市场选用即可，无需关心Agent是怎么构建的。

2.4 记忆系统

Agent的记忆系统决定它能否在多次交互中保持连贯性、学习用户偏好、复用历史经验。所有记忆统一由平台在云端管理，Agent不管跑在本地还是云端，记忆都从云端平台读写。会话上下文管理（滑动窗口、摘要压缩）属于运行时引擎的技术细节，不作为独立记忆层。

2.4.1 工作记忆（短期）

生命周期：单个Agent实例运行期间。跨会话保持任务状态、用户偏好、中间结果。支持TTL自动清理过期数据。统一云端存储，Agent实例通过平台API读写。

2.4.2 长期记忆

生命周期：永久。跨任务学习、经验复用、知识积累。

类型	内容	查询方式
情景记忆	具体任务执行记录	相似度搜索
语义记忆	抽象规则、知识、用户画像	关键词/向量混合

任务完成后自动提取成功模式、错误教训、用户偏好、领域知识。检索采用混合策略（工作记忆40% + 情景记忆35% + 语义记忆25%）。

同一Agent的多个实例之间：工作记忆实时同步（<100ms），长期记忆最终一致性（每5分钟或任务完成后同步），冲突解决用时间戳优先加关键记忆人工确认。

2.5 工具接入系统

所有工具无论来源，统一为标准格式：名称、描述、输入参数（JSON Schema）、输出定义、来源配置、权限控制、执行限制。

来源类型	说明	典型场景
MCP	Model Context Protocol标准	第三方服务
HTTP	任意HTTP API	内部微服务
Native	平台内置工具	文件读写、命令执行
Inline	用户上传的代码	团队自定义逻辑

工具执行在隔离环境中，按隔离强度分四档：无隔离（只读工具）、WebAssembly进程级（内联代码）、Docker容器级（复杂环境）、Firecracker微型VM（不可信代码）。

2.6 技能系统

采用扩展的SKILL.md规范定义技能，包含元数据、接口定义（输入/输出JSON Schema）、实现代码、测试用例。

类型	实现方式	适用场景
原生技能	平台内置	文件读写、HTTP请求
内联技能	用户上传代码（WebAssembly沙箱）	团队自定义业务逻辑
复合技能	多个子技能编排	复杂流程封装

技能市场：发布流程为本地测试→提交→平台自动验证（Schema检查、单元测试、安全扫描）→审核上架。版本管理采用Semver，主版本变更需显式升级。

2.7 权限管控

权限分五个层面，从平台入口到跨平台调用逐层收窄。

2.7.1 平台访问控制

组织（Organization）→ 团队（Team）→ 用户（User）三层结构。角色四个：

角色	权限范围
Owner	组织管理、计费、团队成员管理
Admin	团队管理、成员邀请、Agent发布审批
Developer	创建/编辑/测试Agent、管理技能
Viewer	查看Agent运行结果、只读访问模板市场

用户可拥有多个角色，权限取并集。

2.7.2 Agent资源权限

每个Agent有可见性控制，决定谁能访问：

可见性	谁能用	谁能编辑
私有	仅创建者	仅创建者
团队	团队内所有Developer及以上	创建者 + Admin
指定成员	被授权的特定用户	创建者 + Admin
公开（市场）	所有用户	仅创建者

Agent生命周期对应不同权限状态：草稿（创建者可编辑）→ 测试中（团队成员可测试）→ 已发布（按可见性控制）→ 已下架（仅创建者可操作）。终端用户对市场中的Agent模板只有使用权限，不能编辑原始定义。

2.7.3 运行时权限

Agent定义中包含权限声明，运行时引擎在执行每个工具调用前检查权限。

权限规则采用allow/ask/deny模式，支持pattern匹配：

权限维度	说明	示例
文件访问	Agent能读写哪些路径	read: src/**/*.ts、edit: /tmp/**
命令执行	Agent能执行哪些shell命令	bash: git * 允许、bash: rm * 拒绝
工具调用	Agent能调用哪些MCP工具	mcp__filesystem__read_file 允许
网络访问	Agent能访问哪些域名	webfetch: api.example.com/*
技能加载	Agent能使用哪些技能	skill: internal-* 拒绝

匹配不到任何规则的工具调用默认deny。ask模式触发时暂停执行，提示开发者或用户确认，确认后可选择"仅本次"或"本次会话内同类型全部允许"。

防死循环机制：连续3次权限阻止后暂停并升级到人工确认，累计20次阻止后停止Agent。

2.7.4 数据访问控制

Agent访问企业数据（数据库、API、文件）时，不直接授予权限，而是以用户身份代理访问（OBO，On-Behalf-Of）。用户的认证token传递给Agent，Agent拿着用户token访问下游数据源，数据源按用户已有的权限做行级安全（RLS）。Agent能访问的数据范围不超过使用它的用户本身能访问的范围。

开发者构建Agent时声明需要访问哪些数据源，平台在Agent运行前验证用户是否有对应数据源的访问权限，无权限则拒绝启动。

2.7.5 A2A跨平台权限

Agent A调用Agent B时，平台生成任务级临时token。token包含调用方身份、任务描述、权限范围、过期时间。Agent B拿到token后只能在这个任务范围内操作，任务结束token自动失效。

跨平台调用的权限在Agent Card中声明：每个技能可标注所需的security scheme（OAuth2 scope或mTLS要求）。A2A网络平台的撮合引擎在匹配Agent时检查调用方是否满足目标Agent的security要求。

2.8 运行时系统

运行时系统负责Agent实例的生命周期管理、执行引擎和故障恢复。任务由谁接是A2A网络平台撮合引擎的事，工厂的运行时不做任务调度。

实例管理

Agent被触发后启动实例。云端模式由K8s管理Pod（自动扩缩容），本地模式由Daemon管理进程。平台维护每个实例的健康状态、资源占用、运行时长。

执行引擎

工作流执行引擎按DAG拓扑排序执行，支持并行分支。自主执行引擎按规划→执行→验证三阶段运行，执行中发现新信息可重新规划。

Agent编排

平台内置编排模式库，开发者选择模式而非自己实现编排逻辑。编排是确定性的系统组件，不是Agent。

编排模式	适用场景	工作方式
顺序执行（Sequential）	流程固定、步骤确定	按定义顺序依次调用Agent，前一步输出作为后一步输入
并行执行（Parallel）	独立子任务可同时进行	同时启动多个Agent，聚合结果后继续
监督者模式（Supervisor）	需要根据中间结果动态决定下一步	一个监督者组件负责路由决策，按规则或LLM判断将任务分发给合适的Agent
群涌模式（Swarm）	多个Agent各自处理自己擅长的部分	Agent根据任务描述自行认领，无中心调度
规划-执行（Plan-And-Execute）	复杂目标需要拆解	先规划完整步骤，再逐步执行，执行中可重新规划

开发者可以在工作流画布中混合使用这些模式。比如主流程用顺序执行，某个复杂节点用规划-执行模式拆解，多个独立子任务用并行执行。监督者模式中的路由决策默认用确定性规则（关键字匹配、技能标签匹配），仅在规则无法覆盖时降级为LLM判断，控制成本和可预测性。

任务状态

任务从工厂外部到达（用户直接触发或A2A网络分发）：RECEIVED（收到）→ RUNNING（执行中）→ COMPLETED（成功）/ FAILED（失败）/ TIMEOUT（超时）。重试策略默认3次，指数退避，区分可重试和不可重试失败。

故障恢复

心跳检测（10秒间隔，30秒超时）。Agent故障自动重启（最多3次）。每30秒保存执行状态快照，故障时从checkpoint恢复。

三种运行模式

本地模式：Agent运行在用户机器的隔离环境中，模型调用通过Daemon代理，业务数据不出域。

云端模式：Agent运行在平台管理的K8s集群中，自动扩缩容。

混合模式：Agent运行在本地但可调用云端技能，通过Daemon与云端建立反向WebSocket。

2.9 人机交互形式

这里说的是用户使用Agent时的交互，使用阶段有四种交互模式。

2.9.1 对话式

页面上就是一个对话框，用户说话，Agent回复。Agent的回复不只支持文字，还可以返回表格、图表、文件附件、卡片。用户可以针对回复追问、纠正、补充。

页面布局：左侧Agent列表，右侧对话区域。对话区域顶部显示Agent名称和状态，底部输入框。

2.9.2 流程可视化+实时监控

用户看到Agent正在执行的工作流：当前走到哪个节点、每个节点的输入输出、哪些完成了、哪个正在执行、哪个失败了。节点颜色标记状态（绿色完成、脉冲动画执行中、灰色等待、红色失败）。

用户可以在执行中介入：暂停整个流程、重试失败节点、跳过节点、修改后续参数、手动审批需要确认的节点。

页面布局：上方流程执行视图（可缩放拖拽），下