Agent工厂与A2A网络——AgentMesh设计思路

本文档描述两个独立产品的需求：Agent工厂平台（开发者用来构建和运行Agent的基座，终端用户开箱即用）和A2A网络平台（Agent之间的市场）。两个产品通过A2A协议对接，技术上完全独立部署。

一、背景与定位

1.1 解决什么问题

当前市面上的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正在执行的工作流：当前走到哪个节点、每个节点的输入输出、哪些完成了、哪个正在执行、哪个失败了。节点颜色标记状态（绿色完成、脉冲动画执行中、灰色等待、红色失败）。

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

页面布局：上方流程执行视图（可缩放拖拽），下方节点详情面板（点击展开），右上角操作按钮。

2.9.3 目标委派+阶段性汇报

用户给Agent一个目标，Agent自主规划，但在关键节点主动汇报。

交互过程：用户描述目标 → Agent回复执行计划并确认 → Agent开始执行，每完成一个阶段主动汇报（汇报出现在对话区域）→ 遇到决策点主动问用户（比如数据冲突时问用哪份数据）→ 用户可随时追加约束或调整方向 → Agent最终交付结果。

用户可以随时查看执行进度（对话区域右侧的进度面板），也可以在过程中说"顺便把竞品C也加进来"来调整方向。

2.9.4 后台运行+异常通知

Agent在后台自动跑，用户平时不管，出问题才收到通知。

通知触发条件：执行失败且自动重试也失败、结果超出预期范围、需要人工审批、检测到异常模式。通知通过飞书/Slack/邮件推送，用户点击通知跳转到任务详情页。

任务详情页展示：异常描述（一句话）、执行日志（完整调用链）、Agent的建议处理方案、操作按钮（重试/跳过/修改参数后重试/终止）。

2.9.5 交互模式的切换

四种模式不是互斥的，同一个任务可以在不同阶段自然切换。系统根据任务状态自动展示对应的界面。

典型场景：电商公司的"竞品价格监控Agent"。日常运行用后台模式，Agent每天自动跑。某天价格波动超5%，Agent推送飞书通知。用户点击通知进入流程可视化模式，看到数据采集节点失败。用户在对话框里说"URL改成这个"，Agent确认后重新执行（对话模式）。业务扩展后用户对Agent说"把B公司价格数据也接入"，Agent回复执行计划请求确认（目标委派模式）。

2.10 开发者工具

CLI：init（初始化）、dev（本地调试）、run（单步执行）、publish（发布）、skill（技能管理）、a2a（Agent发现和调用）。

SDK：Python和TypeScript，支持Agent定义、技能引用、模型路由、触发器设置、A2A调用。

IDE插件：VS Code插件，支持Agent可视化编辑、调试集成、技能市场浏览、一键发布。

2.11 工厂与A2A网络的对接

两个平台通过A2A协议通信，不共享数据库、不共享内部API。工厂平台是A2A网络的"客户端"，负责构建和运行Agent；A2A网络平台负责Agent之间的发现、撮合、通信、治理。

对接点有三个：

注册对接：开发者发布Agent时，工厂平台自动将Agent Card（名称、描述、端点URL、能力声明、技能列表、SLA承诺）提交到A2A网络的注册API。注册后A2A网络开始心跳监控，Agent下线时工厂平台主动注销。

任务对接：调用方Agent在A2A网络选定目标Agent后，平台锁定任务并通过A2A协议发送任务。工厂平台的网关收到请求，验证调用方身份和权限（任务级临时token），然后路由到目标Agent（云端直接到K8s Pod，本地通过反向WebSocket转发给Daemon）。执行完成后结果原路返回。

用户直接触发的任务（对话、Webhook、定时任务）不经过A2A网络，由工厂平台实例管理器直接创建Agent实例执行。两种场景走不同入口，但执行引擎和运行时是同一套。

信任对接：每次A2A任务完成后，A2A网络更新信任评分。工厂平台可以查询自己Agent的评分，用于仪表盘展示和决策。争议仲裁时，工厂平台提供执行日志，A2A网络根据日志裁定责任归属。

三、A2A网络平台

A2A网络平台是独立于Agent工厂的基础设施。工厂平台是开发者构建和运行Agent的基座，网络平台负责Agent之间的发现、撮合、通信、治理。两个平台通过A2A协议对接，网络平台不关心Agent内部怎么执行，工厂平台不关心网络层怎么路由。

3.1 网络层（基础设施）

网络层做三件事：Agent之间怎么互相找到（Agent Card）、消息怎么传过去（传输协议）、身份怎么验证（认证）。它是中性的管道。

3.1.1 Agent Card与发现协议

Agent Card兼容Google A2A v1.0标准，是Agent在网络中的"名片"。包含名称、描述、端点URL、版本、提供方信息、能力声明、技能列表、SLA承诺。

发现方式：主动注册（Agent所有者提交Agent Card）、自动注册（工厂平台托管的Agent发布时自动注册）、被动发现（平台定期扫描已知端点更新健康状态）。

3.1.2 传输协议

传输方式	适用场景
HTTP/HTTPS	同步调用，简单可靠
WebSocket	流式输出、状态推送
gRPC	高性能内部通信
消息队列	异步任务、广播

3.1.3 身份认证

支持四种方式：API Key（服务间调用）、JWT（内部短期令牌）、OAuth2（用户授权第三方）、mTLS（企业间高安全）。认证是网络层的安全基础，授权是平台层的事。

3.1.4 本地Agent接入

本地Agent通过Local Daemon接入：Daemon与云端建立反向WebSocket连接，云端为本地Agent生成虚拟端点，外部调用通过云端网关路由到Daemon再转发给本地Agent。业务数据不经过云端。

3.2 撮合层（业务逻辑）

网络层解决了"消息能不能到"的问题，撮合层解决的是"调用方不需要知道哪个Agent最合适"。

3.2.1 注册中心

建在网络层之上的索引层。Agent Card的存储与索引、按技能和领域分类、健康状态实时监控（心跳检测）、版本管理与兼容性检查。

Agent Card通过网络层注册，注册中心解析后建立分类索引。调用方查询注册中心找到候选Agent，再通过网络层发起调用。

3.2.2 两种任务分发模式

点对点调用：调用方明确知道要用哪个Agent，直接通过Agent Card中的端点发起调用。适用于长期合作关系的Agent之间、内部固定流程。

广播认领：调用方不指定目标，把任务描述广播给符合条件的Agent，由Agent自主认领。这是A2A网络平台的核心撮合机制。

广播认领流程：

1. 任务发布：调用方提交任务描述、技能要求、时间要求、质量期望。平台按技能标签预筛选候选Agent池
2. 广播通知：平台将任务推送给候选池中所有Agent。通知包含任务摘要和要求，不包含调用方身份（避免选择性接单）
3. 意向收集：Agent在时间窗口内反馈承接意向，包含预期完成时间、资源负载、相关经验说明。平台只做初步过滤（健康状态、技能版本兼容性、资源充足性），不过滤掉任何符合条件的Agent
4. 方案推荐：平台按多维度生成推荐列表并附推荐理由（历史完成率、平均耗时、当前负载、信任评分），返回给调用方Agent。调用方Agent结合自身策略做最终选择
5. 锁定与执行：调用方Agent选定后通知平台锁定任务，通过网络层建立调用通道执行

推荐排序参考维度：历史同类任务完成率、平均响应时效、当前负载情况、信任评分。调用方Agent可自定义权重或指定特定Agent。

3.2.3 认领准入与质量控制

广播准入：信任评分高于阈值的Agent才进入候选池。高敏感任务（涉及用户数据、金融操作）门槛高，普通任务门槛低。

意向确认：Agent反馈意向后平台快速验证当前健康状态、技能版本兼容性、资源充足性。验证不通过的Agent不进入推荐列表。

执行监控：超时未完成、错误率异常、心跳丢失时，平台触发任务回收（释放当前Agent，重新广播给候选池中其他Agent）。

3.2.4 权限控制

RBAC + ABAC混合授权。支持字段级权限：调用方只能看到有权限的数据字段。跨组织调用需要双向授权，粒度支持组织级、Agent级、技能级。

3.3 信任评分体系

信任评分是撮合层的核心数据，决定Agent在市场中的可见度和竞争力。

评分构成：任务完成率（40%）、响应质量（30%）、响应时效（15%）、可靠性（15%）。每次任务完成后实时更新。

准入阈值：普通任务≥60分，标准任务≥75分，高敏感任务≥90分且额外安全审核。

评分影响：评分高的Agent在广播候选池中排名靠前、注册中心搜索排序靠前、获得更多推荐权重。评分低的被降权（减少广播曝光）或标记警告。低于40分自动下架，60天内可申诉重新上架。

3.4 治理与仲裁

Agent审核：公开发布的Agent需通过平台审核（功能验证、安全扫描、SLA测试）。

争议仲裁：调取执行日志、验证结果正确性、裁定责任归属。仲裁败诉方扣分。

淘汰机制：连续7天心跳失败、低于40分且超过50条评价、被多次投诉的Agent自动下架。

协议兼容性：在A2A v1.0标准之上扩展任务编排协议、信任评估协议、审计协议、广播认领协议。版本兼容通过适配器实现。

四、技术架构

Agent工厂平台和A2A网络平台是两套独立系统，独立部署、独立演进。它们之间的唯一接口是A2A协议。

4.1 两个系统的边界

工厂平台是A2A网络的"客户端"：Agent通过工厂平台注册到网络、从网络接收任务、向网络发布能力。网络平台不关心Agent内部怎么执行，工厂平台不关心网络层怎么路由和撮合。对接点（注册、任务、信任）的详细说明见2.11节。

4.2 Agent工厂平台的技术架构

4.2.1 技术组件

接入层：

组件	职责	选型
Web UI	用户操作界面（对话、流程监控、仪表盘）	React，WebSocket接收实时状态
CLI	开发者命令行工具	Go单二进制
REST API	外部系统集成	OpenAPI 3.0规范

控制层：

组件	职责	选型
API Gateway	请求路由、限流、认证	Kong或Envoy
实例管理器	Agent实例的启停、健康监控、资源管理	自研，云端K8s + 本地Daemon
认证服务	身份认证、权限控制	OAuth2+JWT+API Key+mTLS
记忆服务	工作记忆和长期记忆的存储、检索、同步	云端统一管理

数据层：

组件	用途	选型
PostgreSQL	Agent定义、用户数据、任务记录、工作记忆	JSONB存Agent定义和工作记忆
Redis	任务队列、会话状态	Streams做任务队列
S3兼容	技能包、附件、执行产出物	S3存储（如RustFS）
Qdrant	长期记忆的语义检索	开源，支持混合检索
ClickHouse	审计日志、运行分析	列存，大规模时序分析

运行时层：

组件	职责	选型
K8s集群	云端Agent运行	Pod隔离，HPA自动扩缩容
Local Daemon	本地Agent管理	Go单二进制，反向WebSocket
模型网关	多LLM厂商路由、缓存、降级	统一接口适配Claude/GPT/DeepSeek

4.2.2 记忆系统技术选型

工作记忆：统一由平台云端管理，PostgreSQL JSONB存储（GIN索引支持快速查询）。Agent实例通过平台API读写，不管Agent跑在本地还是云端。TTL自动清理过期数据。

长期记忆：向量数据库（Qdrant）存情景记忆和语义记忆的向量表示，支持混合检索（关键词过滤+向量相似度排序）。关系数据库（PostgreSQL）存语义记忆的结构化部分（规则、知识、用户画像），JSONB+GIN索引支持全文搜索。

记忆提取流程：任务完成 → 轻量模型分析执行日志 → 提取候选记忆 → 用已有语义记忆去重 → 写入向量数据库或同时写入两个库。

4.2.3 核心数据流转

Agent创建：用户提交YAML → API Gateway验证Schema → 存储到PostgreSQL → 解析技能依赖 → 记忆服务初始化存储空间 → 如果设为公开，调用A2A网络的注册API提交Agent Card。

任务执行（对话式）：用户发送消息 → 实例管理器创建Agent实例（按运行时配置选择本地Daemon或云端K8s Pod）→ Agent加载定义，从记忆服务读取上下文 → 调用模型和工具执行 → 结果写入记忆服务 → 推送到用户界面 → 记录执行日志到ClickHouse。

任务执行（工作流）：触发器触发 → 按DAG拓扑执行节点 → 每个节点独立调度执行 → 并行节点同时执行由调度器聚合结果 → 条件分支由LLM判断 → 人工审批节点暂停等待 → 节点状态实时推送到流程可视化界面。

4.3 A2A网络平台的技术架构

4.3.1 技术组件

接入层：

组件	职责	选型
A2A网关	外部Agent调用的唯一入口，协议转换	gRPC/HTTP双协议
管理API	Agent所有者管理注册信息、查看信任评分	OpenAPI 3.0

业务层：

组件	职责	选型
注册中心	Agent Card索引、健康监控	PostgreSQL+Redis，心跳+事件驱动
撮合引擎	广播认领、意向收集、方案推荐、任务锁定	自研，消息队列驱动
认证服务	身份认证、跨组织权限	mTLS+OAuth2
信任服务	信任评分计算、准入阈值管理	事件驱动，每次任务完成更新
仲裁服务	争议处理、执行日志调取	人工+自动混合

数据层：

组件	用途	选型
PostgreSQL	Agent Card、信任评分、任务记录	JSONB存Agent Card
Redis	广播候选池、会话状态	发布/订阅做广播通知
消息队列	异步任务、广播分发	Kafka或NATS，支持消费者组
ClickHouse	审计日志、调用分析	列存时序分析

4.3.2 核心数据流转

点对点调用：调用方通过注册中心查询目标Agent的Agent Card → 认证服务验证调用权限 → 通过A2A网关发送任务 → 网关做协议转换后路由到目标Agent → 目标Agent执行后结果原路返回 → 网关记录审计日志 → 信任服务更新评分。

广播认领：调用方提交任务描述到撮合引擎 → 撮合引擎从注册中心按技能标签筛选候选池 → 通过消息队列广播给候选Agent → 有意向的Agent在时间窗口内反馈承接意向 → 平台初步过滤后生成推荐列表返回给调用方Agent → 调用方Agent结合自身策略选定目标Agent → 通知平台锁定任务并通过A2A网关建立调用通道 → 执行结果返回后信任评分更新 → 失败时撮合引擎触发任务回收重新广播。

Agent注册：工厂平台调用A2A网络的注册API → 提交Agent Card → 注册中心解析建立索引 → 开始心跳监控 → 定时健康检查更新状态。

详见3.2节广播认领流程和3.3节信任评分体系。

4.3.3 Benchmark与质量保证

三层评估框架：技能级（提交时自动测试）、Agent级（标准化场景集Benchmark）、网络级（信任评分，详见3.3节）。

评估方式：自动化流水线 + 人工众包（生成金标准数据集）+ 对抗性测试（构造边界输入）。

质量闭环：发布前达标才允许公开 → 运行中自动收集反馈 → 定期重检检测退化 → 退化超阈值告警 → 数据驱动排序推荐。

4.4 部署架构

工厂平台：开发环境docker-compose（api-gateway、scheduler、memory-service、worker、postgres、redis、qdrant）。生产环境K8s，每个组件独立部署，HPA自动扩缩容。本地一键安装Daemon。

A2A网络平台：独立部署。网关集群（多节点高可用），注册中心和撮合引擎无状态化（状态存PostgreSQL和Redis），消息队列集群保证广播可靠性。

对接：两个平台之间不共享数据库、不共享内部API。所有通信走A2A协议。工厂平台是A2A网络的客户端，网络平台不反向调用工厂平台的内部接口。

五、三方协同场景

以下场景展示了Agent工厂平台、A2A网络平台、第三方Agent三者如何协同工作。

背景：一家汽车制造商（主机厂）需要评估供应商的零部件质量风险。主机厂、一级供应商、第三方检测机构分别使用不同的Agent平台。

参与者：

• 主机厂用我们的Agent工厂平台构建了"质量风险分析Agent"。这个Agent能分析供应商提交的质量数据、识别风险模式、生成评估报告。开发者在工厂平台上定义了Agent的角色、技能（数据分析、报告生成）、工具（数据库查询、PDF解析）、记忆（历史评估经验），发布为模板供质量工程师使用。
• 一级供应商用Dify构建了自己的"质量数据Agent"。这个Agent能查询供应商内部的质检记录、生产批次数据、不合格品处理记录。它通过Dify的Webhook触发，返回结构化数据。它不是用我们的工厂构建的，但实现了A2A协议，注册到了A2A网络。
• 第三方检测机构用自研系统构建了"实验室检测Agent"。它能查询实验室的测试报告、材料分析结果、认证状态。同样注册到了A2A网络。

流程：

1. 主机厂质量工程师在工厂平台上启动"质量风险分析Agent"，输入"评估供应商A的刹车片质量风险"
2. 工厂平台的质量风险分析Agent判断需要获取供应商A的质量数据，向A2A网络发起任务请求
3. A2A网络的撮合引擎广播任务描述（"查询供应商A近6个月的质量检测数据"），按技能标签筛选出候选Agent池
4. 供应商A的"质量数据Agent"（Dify构建）和第三方检测机构的"实验室检测Agent"（自研）都在候选池中，各自认领了能完成的部分
5. A2A网络通过任务级临时token授权，分别与两个Agent建立调用通道
6. 供应商A的质量数据Agent返回近6个月的质检记录和不合格品数据（通过Dify的A2A适配器）
7. 第三方检测Agent返回刹车片材料的实验室测试报告（通过自研的A2A接口）
8. 主机厂的质量风险分析Agent汇总两个数据源，结合自己的长期记忆（历史评估中该供应商的表现），生成风险分析报告
9. 执行完成后，A2A网络根据响应质量和时效更新两个供应商Agent的信任评分
10. 主机厂质量工程师在工厂平台上看到完整的风险评估报告，包含数据来源、风险等级、建议措施

这个场景体现了什么：

• 工厂平台负责构建和运行Agent（质量风险分析Agent的开发、部署、记忆管理）
• A2A网络负责发现和撮合（广播任务、匹配技能、管理信任、授权调用）
• 第三方Agent通过A2A协议自由接入（Dify和自研系统，不需要用我们的工厂）
• 三个平台互不感知内部实现，只通过A2A协议通信