EaiLab/pj0235-eai_agentplatform
11
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e9c0c4007cf3e96117ba8eb6946f83ebc5ab673e
pj0235-eai_agentplatform/docs/09_Research/RS02_外部智能体平台架构对照.md
T
eaiadmin 90031b75f3 docs: 重构仓库文档目录并迁移训练素材 
按当前架构重组 docs 目录，统一中文命名与目录分层，并将训练原材料迁移到独立目录以保持架构文档边界清晰。
2026-09-22 23:23:16 +08:00

79 KiB
Raw Blame History

外部智能体平台架构对照调研

落盘日期：2026-09-19 状态：调研稿（仅供架构决策参考，尚未形成实施结论） 目的：为 pj0235 六层架构「第 1 / 2 / 3 层补缺」提供外部对照基准 关联文档：

  • docs/01_System_Overall/SY21_统一角色技能动作架构.md（六层架构与命名收口）
  • docs/01_System_Overall/SY22_角色技能应用统一任务架构.md（第五层升级为对象层）
  • docs/01_System_Overall/History_And_Retrospectives/2026-09-17_六层架构与三对象建设重点阶段性复盘.md（六层不变，聚焦 5/6 层）
  • docs/09_Research/工作流画布交互研究.md（画布交互调研，本稿不重复其内容）
  • docs/09_Research/01_Benchmarks_And_Mappings/艾翁界面源码深度扫描与办公智能体架构对比.md、docs/09_Research/01_Benchmarks_And_Mappings/微趣我的通用智能体调研与办公智能体架构对比.md（源码级/成品级对比，本稿不重复）

目录

  1. 调研方法与可信度（必读）
  2. 结论摘要
  3. 发现一：行业几乎不讲「层」
  4. 发现二：定义态 / 运行态强制分离
  5. 发现三：编排正在「去图化」，且已分裂成两派
  6. 发现四：Skill 包已经标准化
  7. 发现五：本体层是选答题，但做了就是护城河
  8. 发现六：连接层正在被 MCP 统一
  9. 国内企业级平台的特殊性
  10. 平台详表
  11. pj0235 六层 vs 行业对照与建议
  12. 未查证 / 存疑项
  13. 来源清单

0. 调研方法与可信度（必读）

方法：本次调研由四路并行检索完成 —— ① 编排与工作流型平台；② 大厂 Agent 平台；③ 多智能体框架与协议层；④ 国内企业级智能体/数字员工平台。

重要限制：本次环境下 WebFetch 被全域拦截。实测示例：抓取 laiye.com 返回 Unable to verify if domain is safe to fetch. This may be due to network restrictions or enterprise security policies blocking claude.ai.。因此结论主要来自 WebSearch 返回的搜索摘要与官方文档页片段，部分子调研改用 curl 直取官方文档原文。

可信度分档（正文按此标注）：

档位 判据 举例
高 官方文档 / 官方仓库原文可直接引用 n8n 的 publish 语义、Palantir OMCP、OpenAI「Python-first」、agentskills.io 的 skill 定义
中 官方产品行为可推断，但原话未逐字核到 Coze Studio 的 DDD 分层、各平台的表结构细节
低 仅二手转述或厂商自报，未独立验证 Genspark 全部内容、AG2 的持久化能力（官方与独立分析直接冲突）

引用原则：凡正文写「官方原话」的，均为搜索摘要或直取页面中确实出现过的句子；凡未查证到的一律写「未查到」，不代猜、不补全。

1. 结论摘要

核心判断：pj0235 的「六层架构」提问方式本身不在行业的对话里。行业不按纵向层数描述自己，真正收敛的是另外几件具体的事。

# 发现 对 pj0235 的含义
一 行业几乎不讲「层」，官方分层图只有 Salesforce 一张 六层可作为内部治理语言，但不要假设外部听得懂
二 定义态 / 运行态强制分离是全行业标配 三张定义表无版本快照、无 draft/published；且缺节点级运行表与消息持久化
三 编排「去图化」，分裂为图派与 ReAct 派 补第 3 层时不必默认做 DAG 画布；现有路线更接近 Salesforce / ServiceNow 一派
四 Skill 包已标准化（agentskills.io） 方向已对；可低成本对齐开放标准以吃外部生态
五 本体层只有 Palantir 真做成运行时层 不是必答题；要做就做「小本体」，先映射对象类型 + 动作类型
六 连接层被 MCP 统一，六家大厂全部原生支持 自研连接器 vs 接 MCP，是第 1 层的战略选择

若只挑三条最该动的：

  1. 给三张定义表补 draft/published + 版本快照（第 5 层）
  2. 补 节点级执行记录与消息持久化（第 6 层，本项目已有痛感）
  3. 认真评估连接层直接站到 MCP 上（第 1 层，生态账）

2. 发现一：行业几乎不讲「层」

2.1 各家的官方结构表述

平台 官方如何描述自己的结构
Salesforce 本次调研中唯一有官方层叠图的一家。Trailhead "Salesforce Architecture" 模块画成：Apps & Workflows → Agentforce（Agent Builder / Prompt Builder / Model Builder）→ Platform 内的 Einstein Trust Layer（Data Masking / Dynamic Grounding / Toxicity Detection / Audit Trail / Zero Data Retention）→ Model Ecosystem → Data Cloud
Google build / scale / govern 三支柱（Vertex AI Agent Builder），工程上更常用「Build = ADK / Run = Agent Engine」两段 —— 注意官方用 scale 而非 run
Microsoft 官方无「Foundry + Copilot Studio + M365」这样的纵向层原话，给的是组件表（Agent Runtime / Toolboxes / Models / Observability / Optimization / Identity & Security / Publishing）。接近「层」的叙述是 plane 划分：runtime plane = Foundry Agent Service，governance plane = Agent 365（Entra Agent ID / Purview / Defender），experience plane = Copilot Studio / Teams / M365
Palantir 官方 AIP architecture 页给的是 12 个能力类别（Secure LLM integration / End-to-end observability / Context engineering / The Ontology system / Vector・compute・tool services / Security & governance / Agent lifecycle / Operational automation / Development environments / Human+AI applications / Package・release・deploy…），明确不是纵向层。平台层是 AIP / Foundry / Apollo 三平台
ServiceNow 未查到官方纵向分层。产品侧并列几块：ServiceNow AI Platform、AI Control Tower（治理）、Workflow Data Fabric（数据集成）、AI Agent Fabric（通信骨干）
OpenAI 未查到官方分层。只讲 API 面（Chat Completions / Responses / Agents SDK / AgentKit）与弃用时间表
Dify / Coze / n8n / Flowise / Langflow / Zapier 均无官方分层表述。Dify 代码结构可读出 app → workflow → graphon → tools/rag/plugin；Coze Studio 自称 DDD 分层（api → application → domain → crossdomain → infra）；n8n 是 monorepo 单向依赖（n8n-workflow ← n8n-core ← cli）；Flowise 只有 Capabilities 能力分区

2.2 分层话语的实际来源

「模型层 / 能力层 / 平台层 / 应用层」这类分层话语全部来自研究机构，不是厂商自述：

  • 中国信通院 / 中国电信《2025 政企行业智能体研究报告》：模型层、能力层、平台层、应用层 四层
  • 中国信通院 & 360《企业级智能体技术与应用研究报告（2026）》：模型适配层 — 智能增强层 — 开发治理平台层 三层
  • 华为云 AI-Native 白皮书：应用层含行业大模型 L1 / 场景大模型 L2；算力侧讲异构池化与计算超节点
  • IDC：六层（AI 基础层 / 数据层 / 智能体开发层 / 流程与业务层 / 应用入口层 / 治理与安全层）
  • 《电信科学》：学术六层框架

判断：国内是「先有分层话语、再往产品上套」，通用平台是「先有产品、再被分析师套分层」。

2.3 对 pj0235 的含义

  • 六层作为内部治理语言、文档总纲、长期演进底图继续成立（与 docs/01_System_Overall/History_And_Retrospectives/2026-09-17_六层架构与三对象建设重点阶段性复盘.md 的结论一致）。
  • 但它是你们的私有语言。对外沟通（客户、合作方、评审）时不要假设对方能听懂六层；Salesforce 那种「能力栈 + Trust Layer 横切」的画法更好卖。
  • 不要因为「别人不给层」就动摇 —— 但也不要因为「我们有六层」就认为结构上领先。层级话语不是竞争力，运行时的具体机制才是。

3. 发现二：定义态 / 运行态强制分离

这是本次调研最有价值的一条，因为 pj0235 在这块有明确缺口。

3.1 行业做法

几乎每一家都把 draft 与 published 做成硬隔离，且发布产生不可变版本快照：

平台 机制 来源
n8n 官方原话：「All edits remain in draft until you publish」「Publishing makes your workflow live and locks it to a specific version. Production executions will use this published version, not your latest edits」；可 unpublish、命名版本、提审（Workflow reviews + visual diff） 官方文档
Coze 工作流 Stage 枚举 StageDraft = 1 / StagePublished = 2；实体带 Meta / CanvasInfo / DraftMeta / VersionMeta / HasPublished / LatestPublishedVersion；应用另有 PublishStatus 生命周期（Packing → Packed / Auditing / PublishDone）+ PublishRecordID；数据库直接拆成 draft_database_info / online_database_info 两张表 开源版 Coze Studio
Dify Workflow 表带 version 字段（'draft' 或不可变版本串）；版本控制为 Current Draft / Latest Version / Previous Versions，Publish 把 draft 变成 Latest 并生成新 draft 官方文档
Langflow FlowVersion 表存 id / flow_id / user_id / data（整图 JSON）/ version_number（按 flow 自增）/ created_at，是不可变快照；主 flow 是工作副本；FlowVersionDeploymentAttachment 把版本挂到 Deployment 官方文档
Relevance AI 每次 draft 保存与每次 publish 都自动生成一个版本；草稿不影响已发布版本，restore 会存成带 (restored) 后缀的新 draft，活跃版本标记 Live 官方文档
腾讯云 ADP 配置修改不立即生效，必须显式发布；CreateRelease 管理类接口；每次发布生成一个版本快照，可追溯；提示词也单独有版本记录与「内容对比」diff 官方文档
阿里云百炼 发布是观测与评测的前置条件（「需为已发布的应用」）；官方明确「同一智能体的不同版本被视为不同的、独立的应用」 官方文档

3.2 运行记录是「两族表」，pj0235 只有一族

平台 运行侧数据模型
Dify WorkflowRun（运行）+ WorkflowNodeExecutionModel（节点级，含 inputs / process_data / outputs / status / elapsed / metadata）两族独立模型，Celery 异步执行 + SSE 推流
n8n IRunExecutionData 内含 runData[nodeName] 数组，索引即 runIndex；另有 executionIndex 表示相对发生序
Coze 罗盘 观测单元是 Span，字段含 TraceID / SpanID / ParentID / SpanType / Input / Output / SystemTags / Tags / Annotations；Span 类型含 model / agent / prompt / function / graph / embedding / plugin / vector_store
华为云 AgentArts API 层有 ListOpsTrace / ShowOpsTrace / TagOpsTraceLabel / UpdateOpsTraceFeedback / ListOpsAgentLog；观测对象含应用指标、应用调用链、会话分析、高代码运行数据、分箱工具数据、网关数据、人工标注 Trace、数据回流
LangGraph Checkpointer 在每个 super-step 边界落一个 StateSnapshot；get_state_history() 即天然的执行审计日志；pending writes 保证同一 super-step 内已成功节点不重跑

3.3 会话 / 消息必须持久化

平台 消息与会话
Coze 关系链 Conversation 1─N Section─N RunRecord─N Message
飞书 aily 一等对象含 Run 与 Conversation；应用含审计日志
Claude Agent SDK Session 自动落盘，支持 continue / resume / fork
LangGraph thread（ID，把一串 run 归组）+ checkpoint 链 + Store（跨 thread 长期记忆）
百度千帆 AppBuilder 反面案例：conversation_id 有效期 7 天，且官方问答页明确「暂不支持通过接口查看 conversation_id 对应的历史会话记录」

3.4 对 pj0235 的对照

以代码现状为准（eai_agentplatform/backend-go/）：

项 行业 pj0235 现状
定义态 draft / published 全行业标配 无。specialist / skill_definition / xapp_definition 三张表改完即生效，没有「发布」这个动作
定义版本快照 全行业标配 无（有一处易误判，见下）。无不可变快照表，无「从某版本发布」的概念。
注意：specialist 表确实有一个 version 字段（size:32;default:''），但它是展示用自由文本 —— specialists/runtime/records.go 里写作 firstNonEmpty(item.Version, "v1.0")，由 admin 接口直接赋值，既无快照也无发布语义。skill_definition 与 xapp_definition 连这个字段都没有
运行实例表 有（task_run） 有 ✅
节点级执行表 全行业标配 无。task_run 只有整体状态，步骤进度无处安放
产物表 有（task_artifact） 有 ✅
消息 / 会话持久化 全行业标配 无。对话内容不入库，前端 frontend/src/store/taskRuntime.js 内存态

已有痛感印证：本项目已知问题「task_run 的 status 恒为 done，步骤进度不在 run 表里，配对靠中文名、改名即静默断链」—— 这正是节点级执行记录缺失的直接后果，而这一层在全行业都是标配。

4. 发现三：编排正在「去图化」，且已分裂成两派

pj0235 缺第 3 层（总线与编排）。行业本身没有统一答案，这对补层方式的选择有直接影响。

4.1 图派（DAG / 状态图）

平台 编排模型
Dify DAG + 事件驱动。图由 GraphEngine 在 worker pool 上调度，事件流式（GraphRunStartedEvent → Succeeded / PartialSucceeded / Failed / Aborted / Paused）而非返回单值；支持迭代/循环、human_input 暂停与恢复（存 WorkflowResumptionContext，从暂停点续跑不重放整图）；步骤持久化
n8n DAG，但官方强调 「画布 ≠ 执行」。Workflow 类把定义对象转成运行时图；数据单位是 item 数组；连线不隐含顺序（起始节点按画布 Y 排序）；SplitInBatches 不是语言循环，靠恢复已存执行状态推进
Coze DAG（Eino 图编排）。BuildAgent 把 SingleAgent 编译成 compose.Runnable；有工具时从简单 chat 节点切成 ReAct Agent；图拓扑三阶段（并行预处理 → 提示词组装 → LLM 推理）；默认同步运行（超 10 分钟超时），可开异步（延到 24h）
Langflow 原生 LangGraph，是这批里唯一能表达带环状态图的（cycles / conditional routing / state machine），不只是 DAG；有 Freeze（冻结组件及其上游不再重算）
Microsoft Agent Framework 的 Workflows 是图（executor + edge），带 type-safe routing、checkpointing、HITL
CrewAI Process.sequential / Process.hierarchical 两种（Process 是 Enum）；要更自由须下沉到 Flow（@start / @listen / @router + self.state）

4.2 ReAct / 交接派（新，且是大厂主场）

平台 编排模型
Zapier Agents 明确不是 DAG，是 ReAct 推理循环：读指令 → 看请求 → 决定下一步（调工具 / 检索知识 / 交给另一个 agent / 反问）→ 循环至终答；可在歧义、报错、鉴权失败或预设决策点暂停等人
Salesforce Agentforce 单 agent + Topic/Action，靠 Atlas Reasoning Engine 跑 ReAct 循环（Goal → Reason → Act → Observe → Evaluate → Refine）。既不是 handoff，也不是图。官方建议每个 Topic 不超过 15 个 Action
ServiceNow 编排者-工作者。Orchestrator 用 ReAct prompt（把 reflection 与 planning 合并），并引入 Route 调度模式做异步并行工具执行；候选 agent 超过理想区间（8–10 个）时用 Dynamic Orchestrator 做映射
OpenAI Agents SDK 官方原话：「Python-first，用语言特性编排，而不是学新抽象」 —— 即不是图编排。两条路径：handoffs（转移控制权）与 agents as tools（保留控制权）；官方选择标准是「专家只做有界子任务就用 agents-as-tools，路由本身是工作流一部分就用 handoff」
OpenAI Swarm 全部抽象只有 Agent + handoff（handoff 就是「一个函数返回另一个 Agent」）。完全无状态：README 明确写「does not store state between calls」。自身标为 experimental / educational，已被 Agents SDK 取代
OpenAI Deep Research 最极端：官方原话「trained using end-to-end reinforcement learning on hard browsing and reasoning tasks」——规划、反思、工具使用被 RL 训练进模型权重，而不是靠外部编排层
Google ADK sub_agents 树 + LLM 驱动 transfer；另有确定性的 SequentialAgent / ParallelAgent / LoopAgent（不调 LLM，顺序有保证）与 AgentTool。注意 ADK 2.0 中模板工作流已被 graph-based workflows 与 dynamic workflows 取代

4.3 对 pj0235 的含义

  • pj0235 现有路线（ChooseTaskStrategy 二选一 + SY23 的「专员岗位说明书进 prompt」）形态上更接近 Salesforce / ServiceNow 那一派（角色路由 + ReAct），而不是 Dify 那块 DAG 画布。
  • 因此：补第 3 层时不必然要做工作流画布。是否真做画布，值得单独拍板 —— 这是本稿能省下的最大一笔投入。
  • 若要做画布，docs/09_Research/工作流画布交互研究.md 已有交互层准备；但该稿是交互调研，不含编排引擎与运行记录设计。

5. 发现四：Skill 包已经标准化

5.1 Agent Skills 成为开放标准

2025-12-18 发布为开放标准，规范站 agentskills.io。官方首页定义：「a skill is a folder containing a SKILL.md file」，标准布局：

my-skill/
├── SKILL.md      # 必需：metadata + instructions
├── scripts/      # 可选：可执行代码
├── references/   # 可选：文档
├── assets/       # 可选：模板、资源
└── ...

目标写明是「build a skill once and use it across any skills-compatible agent」。

采纳情况（这是判断「是不是真标准」的关键证据）：

采纳方 证据
Claude Code 官方明说自己 follow 该开放标准，只在其上加扩展，并在文档里逐项标注哪些 frontmatter 字段属于标准、哪些是扩展。上传到 claude.ai / Skills API 时只接受标准那六个字段（name / description / license / compatibility / metadata / allowed-tools），乱加字段会直接报错
MCP 官方 新增专页 "Build with Agent Skills"，提供 mcp-server-dev 插件，内含 build-mcp-server / build-mcp-app / build-mcpb 三个组合 skill，明说「the files follow the open format and work with any agent that implements the standard」
Google ADK 已把 Skills 列为一等扩展机制，文档直接链到 agentskills.io
OpenAI Agents SDK Sandbox 的 Capabilities 里放了 Skills（与 Filesystem / Shell / Memory / Compaction 并列）

5.2 两个值得直接借鉴的设计点

（1）渐进式披露三级加载。官方原话：「Progressive disclosure is the core design principle that makes Agent Skills flexible and scalable.」

级别 内容 何时进上下文
Level 1 每个已安装 skill 的 name + description 启动时预载进 system prompt（约 100 token/skill）
Level 2 SKILL.md 正文 任务匹配到该 skill 时才整篇读（官方建议正文 ≤ 500 行）
Level 3 目录内被引用的附加文件（reference.md 等） 真正需要时才读

关键补充：脚本经 Bash 执行，脚本本身与它处理的数据都不进上下文窗口，只有输出进，且代码是确定性的、可重复的。因此官方称一个 skill 能打包的上下文量「实际上是无限的」。

（2）纯文件系统制品，无需反注册。Claude Agent SDK 官方原话：「Unlike subagents... you create skills as files on disk. The SDK doesn't provide a programmatic API for registering them.」—— 删目录即卸载。

安全边界：官方强调只从可信来源安装并审计不可信 skill，因为恶意 skill 可能引入漏洞或造成数据外泄。

5.3 Skill / MCP tool / function 的定位差异

三者不在同一层，是互补的三层：

  • OpenAI function / MCP tool 解决「动作」层：带 JSON Schema、可调用、无状态、输入输出明确。
  • MCP 在此之上加「接入标准化」：一次编写、到处接入。
  • Skill 解决「程序性知识与上下文」层：不是可调用函数，而是一包指令 + 资源 + 脚本，回答「这类任务该怎么做」。

比喻（官方口径）：MCP tool 是 API，Skill 是操作手册（官方原话是「像给新员工准备一份 onboarding guide」）。

5.4 对 pj0235 的含义

  • 本项目 backend-go/internal/skills/packages/（22 个包）+ specialists/packages/，以及 docs/02_Architecture/AR11_技能专员连接器可删除封装规范.md 的「可删除封装」思想，与开放标准方向完全一致。
  • 值得做的低成本动作：对齐 agentskills.io 的 manifest 字段（name / description / license / compatibility / metadata / allowed-tools）。成本很低，但换来的是将来能吃外部技能生态。
  • 值得评估的动作：本项目的技能定义目前是全量进 prompt 还是三级加载？若为全量，则随技能数增长会线性吃掉上下文 —— 渐进式披露是行业已验证的解法。

6. 发现五：本体层是选答题，但做了就是护城河

6.1 六家大厂里只有 Palantir 真做成运行时层

判断依据不是营销页，而是可配置的产品行为。Palantir Ontology MCP（OMCP） 官方原文：

Each action type included in the application becomes its own MCP tool, so agents can invoke a specific, predefined action to write data into the ontology

且定位是「designed for ontology consumers: external AI agents that need to safely write data to your ontology」，并通过 application restrictions 限制 agent 可执行的动作集。

即：对象类型 = 读，Action Type = 写，Function = 算，三条通道都直接映射成 agent 工具，权限由 Ontology 侧统一裁决。这已超出「语义检索层」，是运行时的对象-动作总线。

Palantir 另有一组分工明确的 MCP：OMCP（面向消费者，能写生产 ontology 数据）与 PMCP（面向 builder，70+ 工具，不能写 ontology 数据，只改结构）。

6.2 其余五家分三档

档位 平台 判断
最接近但性质不同 Salesforce Data Cloud 确实是官方层叠图里的独立一层，也确实在运行时被 Dynamic Grounding 使用。但它是数据层（实时 lakehouse + 统一 profile + vector DB），没有可写回的业务动词一等对象。真正在运行时横切所有请求的是 Einstein Trust Layer（masking / grounding / toxicity / zero-retention），那是合规层不是本体层
有能力、未成层 Microsoft Dataverse 的 table/column + semantic model/glossary 是真实的业务语义设施，Copilot Studio 会用它把自然语言改写成结构化查询。但官方资料显示该 semantic model 目前并不覆盖 Dataverse MCP Server，两套语义路径分叉；Dataverse 也从未被画成 agent 架构的独立一层
部分具备 ServiceNow CMDB + CSDM 事实上就是它的对象模型，官方 blueprint 称其给 AI「real-time awareness of who is involved, what assets are affected」。但没有独立成层，也没有公开的「对象类型 → agent 工具」映射机制
没有 OpenAI / Google ADK 的 Session / State / Memory / Artifact 是上下文与状态管理，不是业务语义对象；OpenAI 的 Session 同理。两家的 RAG 能力（Vertex AI Search、File Search）是检索层而非对象层

一句话：Palantir 的本体是运行时执行面（execution plane），Salesforce 的 Data Cloud 是运行时取数面（grounding plane），其余四家最多是检索面或数据底座。

6.3 国内反而有跟进者

厂商 本体设施
用友 BIP 6 YonOnto 企业本体平台，定位「语义中枢 / 语义护栏」，围绕客户、供应商、产品、组织、员工、合同、订单、项目、资金、资产建模，支持业务本体 / 数据本体 / 文档本体，提「活态闭环 Living Loop」；配套 YonWork 企业 AI 工作台，并有「本体智能体（Ontology-Driven Agent）」与 LOM 本体大模型（2026-02）
中电金信 「源启·智能决策操作系统」采用「本体 + 智能体」，由本体管理平台（OMP） + 本体智能体管理平台（OIP） 组成。OMP 结构化沉淀对象、关系、动作、规则、权限、数据标准和版本体系，并统一管理智能体 / 知识库 / MCP 服务 / CapaMesh
腾讯云（技术文章） 给出本体作为「智能体的世界模型」「多 Agent 共享黑板」「审计闭环」等协同模式，并有一句可引用的判断：「大模型越强，本体论越重要，而不是越不重要」

海外同类参照：Microsoft Fabric IQ Ontology（可从已发布语义模型一键 Generate Ontology，作为 Foundry IQ 的知识源供智能体运行时查询）、AWS《Semantic Layer for Agentic AI using Ontology, Symbolic Reasoning, and Virtual Knowledge Graph》（本体 T-Box + 实例 A-Box，神经符号 AI）、Databricks Genie Ontology。

6.4 对 pj0235 的含义

  • 本项目第 2 层现状：只剩 ontology_binding_json 一个自由文本字段（backend-go/internal/skills/model/skill_definition.go「字段可存可校验，运行时无人读取」），无对象类型 / 动作类型 / 状态类型 / 关系类型体系。
  • 行业现实：这东西不是必答题（六家大厂五家没有），但做了就是护城河（Palantir 的差异化几乎全在这里）。
  • 务实路径：以本项目「先通用、后行业包」的路线，先做「小本体」 —— 把对象类型 + 动作类型两样映射到已有的 skill / action，让本体立刻在运行时可用（即复刻 Palantir 的「Action Type → 工具」最小机制），而不是先搞理论本体论。

7. 发现六：连接层正在被 MCP 统一

7.1 六家大厂全部原生支持 MCP

平台 MCP 支持 原有连接体系
ServiceNow AI Agent Fabric 定位「communication backbone」，走 MCP + A2A；Zurich Patch 1 起 ServiceNow AI Agent 可作为 MCP client（协议版本 2025-03-26，支持 authless / API key / OAuth 2.1） Integration Hub / Workflow Data Fabric（zero-copy 连 450+ 系统如 SAP、Salesforce）
Salesforce Agentforce 3 起原生支持（自带 MCP client，连 Salesforce 托管或外部 MCP server） MuleSoft —— MCP Connector、Flex Gateway MCP 支持、API Catalog 把 MCP server 同步进 org、Agentforce Registry 做白名单；MuleSoft Agent Fabric / Agent Registry 做跨平台 agent 发现
Microsoft Toolbox「groups those tools into a single, reusable unit … one managed MCP-compatible endpoint」；另有 Dataverse MCP Server、远程 MCP Power Platform connectors（官方称 1,400+ 企业数据源）
Google MCP 是 ADK 一等工具类型，Agent Engine 内置 MCP client；Cloud API Registry（Preview）管 MCP server 与 tool 白名单 Integration Connectors（100+ 企业应用）、Apigee API Hub、Application Integration
OpenAI MCP 是一等工具类型（「MCP server tool calling: Built-in integration that exposes remote MCP tools」）；Connector Registry 供管理员统一管数据/工具连接 预置连接器（Dropbox、Google Drive、SharePoint、Teams）
Palantir OMCP + PMCP（见 §6.1） Pipeline（batch / streaming / CDC）

7.2 MCP 自身的分层

MCP 自己分成两层：

  • Data layer —— 基于 JSON-RPC 2.0，含版本与能力发现、核心原语、通知
  • Transport layer —— stdio / Streamable HTTP，含连接建立、消息分帧、鉴权

Data 是内层、transport 是外层。

原语分两侧：

  • Server 侧三个核心原语：Tools（可执行函数）、Resources（上下文数据源）、Prompts（可复用交互模板），各有 */list、*/get，tools 另有 tools/call，列表是动态的。
  • Client 侧：Elicitation（server 向用户要补充信息或确认，走 elicitation/create）。

注意一处较新变化：Sampling 与 Logging 已在协议版本 2026-07-28 被标记为 deprecated（新实现应直接对接 LLM provider API / 写 stderr 或用 OpenTelemetry）—— 许多二手资料仍在写 sampling，引用时需注意时效。

协议自身是无状态的：每个请求在 _meta 里带协议版本与该请求相关的能力，server 不从前序请求推断；server 通过强制的 server/discover 宣告支持的版本与能力。另有可选 extensions，如 Tasks 扩展让 server 为长时请求返回持久句柄供 client 轮询。

7.3 A2A 与 MCP 的分层关系

A2A 官方文档自己给出了最干净的分层表述：

MCP is vertical. It deepens a single agent. 每加一条 MCP 连接，就给 agent 多一件工具、资源或技能。

A2A is horizontal. It connects agents across that boundary. 对方 agent 可能属于另一个团队、另一个部门或合作伙伴组织。

Used together, MCP gives each agent depth, and A2A gives your system reach.

核心分野：A2A 明确规定「对 client 而言，remote agent 是一个不透明的黑盒：其内部机制、记忆与工具保持隐藏」—— 这与 MCP「工具必须是结构化、可描述」的假设根本冲突，也是两者不能合并成一个协议的原因。

A2A 的任务生命周期（对设计运行态有参考价值）：agent 可回 Message（即时、无状态）或 Task（长时）。Task 会进入中断态（input-required / auth-required）或终态（completed / canceled / rejected / failed）；终态后不可重启，同一任务的后续细化必须在同一 contextId 下新建 task。核心元素含 Agent Card（发现）、Task、Message、Part（oneof text/raw/url/data）、Artifact（有 artifactId，可增量流式推送）、contextId。

把多层画进同一张图的三家：A2A 官方文档自身；AGNTCY（唯一把「本体/模式层」显式画进栈图的：OASF 模式层 + Agent Directory Service 发现 + Identity 身份 + SLIM 传输 + SHADI 运行时沙箱 + Observability 横切）；MCP 官方新增的 "Build with Agent Skills" 页（承认 skill 层与 tool 层是两回事）。

学术判断：一篇 2026-06 的 taxonomy 论文（对 9 个活跃协议做五维分类）结论是——短期存在收敛压力，会走向统一 agent-to-agent 与 agent-to-context 通信的协议；但长期看没有任何单一协议能同时最大化通用性、效率与可移植性，领域更可能演化成联邦式、分层化的协议栈。该文同时指出去中心化发现目前仍然罕见。

7.4 对 pj0235 的含义

  • 本项目 backend-go/internal/connectors/ 结构为 api / core（含 contracts）/ packages / query / registry，只有 packages/kingdee 一个真实现，其余为代码内静态 demo；且无 connector_definition / connector_binding 表（无绑定、无 DB 模型）。
  • 战略选择：继续自研连接器协议，还是把 MCP 作为连接层的标准？本项目的「连接器」概念（外部系统查询链路 + registry + 可卸载包）与 MCP server 几乎同构。接 MCP 等于免费获得生态；不接则每条连接器都要自己写一遍。
  • 不能忽略的现实约束：RPA 兜底是国内 to B 绕不开的一只脚。钉钉把**拟人操作（RPA）**列为 AI 助理四类能力之一（DDAutomator 框架 + ai-plugin.json 协议）；来也 CEO 在 InfoQ 访谈里的原话是「别被 MCP 的包装骗了…关键时刻还是 RPA 兜底」。老旧 C/S 系统、无 API 的国产软件、信创环境都不吃 MCP 这一套。

8. 国内企业级平台的特殊性

8.1 唯一与 pj0235「三对象」同构的官方口径

来也科技自述三层，是本次调研中唯一与「专员 / 技能 / 应用」结构真正同构的官方口径：

  1. 技能层（Skill Layer） —— 解决「能不能干好活」，能力引擎为 APA（智能体流程自动化，确定性执行）、ADP（文档处理）、ACX（客户体验）、Revor AI。官方比喻：「APA 是手，ADP 是眼，ACX 是记忆。」
  2. 执行层（Execution Layer） —— Laiye Worker，「每位员工的持久化数字伙伴」，理解目标、编排技能、与人协作，管理跨天跨周的长周期多步骤任务，异步推进、关键节点由人审阅。
  3. 控制平面（Control Plane） —— Laiye Shifu，面向管理者和 IT，提供可审计、可观测、可共享、可控制的企业级治理。

关键界定：「数字员工」是平台整体叫法，不是某个产品名；具体产品叫 Laiye Worker。APA 把流程沉淀为自然语言流程文档并做确定性执行、自愈与验证，让流程从「一次性脚本」变「可长期复用的资产」。

其他可参照的层级口径：

  • 联通 UniEmployee（开源）：Employee → Workflow/SOP → Skill → Connector → Tool 五层能力模型，技能以 SKILL.md 沉淀（含触发条件与执行步骤），关键业务流程用 StateGraph 状态机固化（含人工审批节点）
  • 社区提出的三层：工具（Tool）→ 数字员工（Digital Employee）→ 智能体平台（Agent Platform），中间层被定义为「多工具组合的业务流程模块」
  • 浪潮海岳 Mano Team：以「企业角色封装」定义数字员工的岗位边界与能力标准，分个人助理型与专家岗位型，三级能力等级（个人助理级 / 业务协作级 / 自主员工级）

重要提醒：「岗位」在国内多数厂商那里只是交付话术，不是对象模型。金智维原话「智能体是大脑负责思考规划，RPA 是双手负责执行落地，数字员工是面向岗位的自动化交付」—— 这里的「岗位」不在对象模型里。只有来也把它做成了真实架构层。本项目 SY23 走「专员岗位说明书」方向是对的，但不要被话术带偏。

8.2 国内平台 vs Dify / Coze 这类通用平台的明显差异

  1. 「工作流」的地位不同 —— 国内大厂把它当交付物，不一定当一等对象。百度千帆官方原话最极端：「组件是用于扩展智能体应用能力边界的配置项，工作流是创建组件的编排工具」（工作流是造组件的工具，组件才是被引用对象）。华为盘古的工作流也可脱离应用独立存在且导出为 JSON 资产。而 Dify / Coze 语境里，工作流就是与应用并列的一等对象。这个差别会直接影响对象模型的顶层设计。

  2. 分层话语权在研究院和生态厂商，不在平台文档里 —— 见 §2.2。

  3. 信创与私有化是硬约束，不是选项 —— 金智维把「全栈信创适配」做成核心卖点（全自研 C/C++ 微内核 + 麒麟/统信 + 鲲鹏/飞腾/海光/兆芯/龙芯 + 达梦/人大金仓）；影刀兼容统信 UOS 与银河麒麟；悟空提供行业专属模型私有化部署；来也 Worker 强调本地脱敏、敏感数据不出本地。Dify 的私有化是「可以 Docker 部署」，国内厂商的私有化是「必须适配国产 OS/CPU/DB 并拿到认证」。

  4. 治理不是「加个可观测」，而是内置审计与控制面 —— 来也专门做了 Laiye Shifu 控制平面；华为 AgentArts 的治理对象细到分箱工具、网关、人工标注、数据回流，API 层就有 TagOpsTraceLabel / UpdateOpsTraceFeedback；悟空的安全是「架构在安全体系之上」（双层规则 + 权限取用户权限与提问人权限的交集 + 容器级沙箱 + Skill 上架扫描 + 运行时 Policy 引擎阻断 + 网络请求可追溯）；飞书 aily 的知识检索继承飞书云文档 ACL（用户仅能检索自己有权限访问的云文档）。

  5. RPA 是默认存在的一只脚，通用平台完全没有 —— 见 §7.4。

  6. 「数字员工」是行业级一等叙事 —— Dify / Coze 的最上层对象是「应用 / 智能体」，不存在「岗位」这一层。

  7. 会话持久化口径普遍比通用平台更「克制」，且写法各不相同 —— 百度千帆 7 天且不支持回查历史会话；腾讯 ADP 在 2025-11 把「应用变量」从 Session 隔离改为非 Session 隔离（跨会话可读写）；扣子罗盘用 Redis 存 PreSpanID 链支持会话历史查询；飞书 aily 技能 API 同步 1 分钟超时、不支持流式。

  8. 反过来说，通用平台在 AgentOps 工程化上确实领先国内大厂平台 —— 除扣子（扣子罗盘是国内最完整的 AgentOps，独立成产品：评测集 / 评估器 / 实验，离线 + 在线评测，Trace 回流评测集）与华为 AgentArts 外，其余国内平台的「评测 — 发布版本 — Trace 回流」闭环大多不完整：百度千帆基本没有，腾讯元器没有，飞书 aily 只有审计日志。

9. 平台详表

9.1 编排与工作流型平台

平台 一等对象 分层口径 编排模型 运行记录 扩展机制 定义文件形态
Dify App（workflow / chatflow / agent / completion 四模式）/ Workflow / Tool / Knowledge(Dataset) / Plugin（六类）/ Model 官方无明示分层；代码分 app → workflow → graphon 引擎 → tools/rag/plugin，引擎内有 Layer 扩展层（WorkflowPersistenceLayer、LLMQuotaLayer、ObservabilityLayer、PauseStatePersistenceLayer） DAG + 事件流；多步链式，支持迭代/循环/human_input 暂停恢复（WorkflowResumptionContext，不重放整图）；步骤持久化 WorkflowRun + WorkflowNodeExecutionModel 两族表，Celery 异步 + SSE Plugin Daemon（独立 Go 服务）+ .difypkg(ZIP) + manifest.yaml + Marketplace（RSA-4096 签名校验，50MB 上限） YAML DSL（version / kind / app / workflow / dependencies）+ REST API + CLI（difyctl）
Coze / 扣子 工作空间 → 项目 → 智能体 / 应用 / 工作流（含对话流 Chatflow）/ 插件 / 知识库 / 数据库 Coze Studio 自称 DDD 五层：api（Hertz）→ application → domain（agent/workflow/conversation/knowledge/memory/plugin 六域）→ crossdomain → infra；另有 Apache Thrift IDL 层 DAG（Eino 图编排）；有工具即切 ReAct Agent；三阶段图拓扑；默认同步（超 10 分钟超时），可开异步（24h） RunRecord（Status / Error / Usage）；Conversation 1─N Section─N RunRecord─N Message；发布状态机 PublishStatus 插件商店 + 自定义插件（同插件内工具须同域名） 工作流以 DSL 存库转可执行图；对外发布为网页 / API / SDK
n8n Workflow / Node / Connection / Execution / Credential / Agent（预览） monorepo 单向依赖：n8n-workflow ← n8n-core ← cli；三层执行数据 item → run → execution（社区总结，非官方原话） DAG，画布 ≠ 执行；item 数组为单位；连线不隐含顺序；SplitInBatches 靠恢复状态 IWorkflowBase（定义） vs IRunExecutionData（运行，含 resultData + executionData 调度态）；手动/部分/生产三模式，生产只跑已发布版本 npm 包，n8n-nodes-* 前缀 + n8n-community-node-package keyword + package.json n8n 字段注册 JSON 定义文件 + REST API + SDK + Git source control
Flowise Flow（Assistant / Chatflow / Agentflow）/ Node（= Integration）/ Tool / Variable / Evaluation 官方无分层，只有 Capabilities 能力分区 Agentflow V2 显式编排 + node-dependency/execution queue；支持循环/分支/HITL；Flow State 管共享数据 Execution logs / visual debugging / Tracing & Analytics（外接 Arize、Langfuse 等）；原生 Prometheus 仅高层指标（官方明说「only high-level metrics」） Integrations + Template marketplace + 自定义 JS 节点；MCP client/server 导出 JSON flow；REST API + Python/TS SDK + CLI；无 YAML
Langflow Flow / Component / Project / FlowVersion / Deployment 官方无分层；组件按 Core components（按用途分组）/ Bundles（按厂商）/ Legacy 分组 原生 LangGraph：带环状态图（cycles / conditional routing / state machine），唯一非纯 DAG 者；可单组件跑或整图跑；有 Freeze FlowVersion 表（不可变快照 + version_number + DeploymentAttachment）；/v1/monitor/*；原生 trace 落库 + 多家 tracer Custom Components（继承 Component 的 Python 文件，放进目录即加载）+ Bundles + Tool Mode + MCP JSON（导入导出 ZIP）+ REST API + lfx DevOps SDK（.lfx/environments.yaml + flows/ JSON 版本化）
Zapier Agents Agent / Tool（= app action，7000+ 应用 / 30000+ 动作）/ Knowledge source / Trigger / Zap / Table / Pod / AI Actions 仅第三方索引（MIT AI Agent Index）给出 model layer / observation space / action space，非官方 ReAct 推理循环（非 DAG）；可暂停等人工；agent 之间可互相调用（agent-as-tool） Activity dashboard + All Activity + run history + trace（tool calls / errors）；评测用三层金字塔（单元式 evals / trajectory evals / A/B 分阶段发布）；表结构闭源未查到 AI Actions API + Zapier MCP（8000+ 应用 / 30000+ 动作）；无包格式概念 纯 UI / 表单编排；未查到 YAML/JSON DSL 或 SDK
Relevance AI Agents（the workers）/ Tools（the actions）/ Workforces（the team）/ Knowledge（the context）+ Task / Version / Node / Trigger 未查到官方分层 图（workforce canvas）+ 两种边语义：AI connection（自主交接）vs Next step（强制顺序）；Tool 内部线性 steps。已知限制：agent 通信单向，subagent 一次只跑一个、不并行 Task（一次运行，含 status / credits / run time / linked tools，Running / Completed / Paused / Timed out）；版本历史（Live 标记）+ Evals（可要求 eval 通过才能发布） Tools 步骤库 + 任意 API + 自定义 Python；Marketplace 克隆/提交 UI 编排 + Invent 自然语言构建；未查到公开 DSL 或 SDK

9.2 大厂 Agent 平台

平台 一等对象 编排模型 会话与运行记录 本体层地位 连接层机制
OpenAI Agent / Handoff / Guardrail / Session / Tool / Trace·Span；平台侧 Agent Builder / Connector Registry / ChatKit handoff + agents-as-tools（非图，官方明说 Python-first） Session 持久化（InMemory / SQLAlchemy / Redis / MongoDB / 加密）；Tracing 落 trace/span；Evals 与 trace grading；HITL 专章 无 MCP 一等工具类型；Connector Registry 管预置连接器
Microsoft Agent（prompt / hosted 两型）/ Conversation / Tool / Toolbox Agent Framework：sequential / concurrent / Group Chat / Handoff / Magentic + 图 workflow（executor + edge，带 checkpointing、HITL）；平台侧 A2A + MCP 会话级持久化 + 三种 memory（procedural / user / session）；OTel tracing；Foundry evaluations + Agent optimizer Dataverse 语义模型存在，但偏数据/检索层，未覆盖 Dataverse MCP Server，未单列成层 MCP 全面（Toolbox 单端点、Dataverse MCP）；原有 Power Platform connectors（1,400+）
Google Agent(LlmAgent) / Tool / Session / State / Event / Memory / Artifact / Runner / sub_agents sub_agents 树 + LLM transfer；Sequential / Parallel / Loop 确定性 workflow agents；AgentTool；Graph Workflows；A2A Session 三后端；Events 记录完整执行史；Memory Bank 跨会话；Agent Engine evaluation + Cloud Trace 未查到 MCP 一等；Cloud API Registry 管 MCP；原有 Integration Connectors（100+）、Apigee API Hub
Salesforce Agent / Topic / Action / Instruction / Subagent / Agent Script 单 agent + Topic/Action，Atlas 跑 ReAct；无 handoff、无图。官方建议每 Topic ≤ 15 个 Action Session Tracing Data Model（基于 OpenTelemetry）；Command Center 实时观测（延迟/升级率/错误率）；Testing Center 会话回放与 backtesting；Trust Layer audit trail Data Cloud 是单独一层且运行时真在用（Dynamic Grounding），但属数据层，非对象-动作语义层 Agentforce 3 原生 MCP client；MuleSoft（MCP Connector、Flex Gateway、API Catalog、Agent Registry）；A2A
Palantir Object Type / Object / Property / Link Type / Action Type / Function / Object Set / Interface 无固定范式：AIP Logic（低代码）或 Code Workspaces（专业代码）做 durable orchestration；运行时是「LLM 推理 + Ontology grounding + 工具执行」 端到端 observability（每个 action 有日志、可追 chained execution）；AIP Evals 与 Ontology 联动；动态安全（role-/marking-/purpose-based）+ audit logging 核心卖点，且运行时真的用（见 §6.1） OMCP（可写生产 ontology）/ PMCP（builder 侧，70+ 工具，不写数据）；Pipeline 做 batch/streaming/CDC
ServiceNow AI Agent / AI Agent Orchestrator / AI Agent Studio / Use Case / Tool / Trigger / AI Agent Fabric 编排者-工作者：Orchestrator 为中心，ReAct prompt + Route 调度支持异步并行工具；Dynamic Orchestrator 做候选过多时的路由；支持 user impersonation 成套 eval（traces / metrics / issues / optimization）、guardian、kill switch、LTM 分类；治理上收 AI Control Tower 部分：CMDB/CSDM 是真实操作对象，官方 blueprint 称其给 AI「real-time awareness」；但未单列成层，也无 Action → 工具的公开映射 AI Agent Fabric 走 MCP + A2A；原有 Integration Hub / Workflow Data Fabric（zero-copy 连 450+ 系统）

9.3 框架

框架 一等对象 状态持久化 多智能体模型 扩展机制
LangGraph State / Node / Edge / Checkpointer / Store。没有「Agent」这个一等对象 Checkpointer + thread_id；每个 super-step 一个 checkpoint（StateSnapshot）；pending writes 保证同 super-step 内成功节点不重跑；InMemory / Sqlite / Postgres / Mongo；Store 管跨 thread 长期记忆；durability sync/async/exit。已知坑：PostgresSaver 的 thread_id 要 < 255 字符；checkpoint 会无界增长需定期裁剪 无内建角色抽象，靠子图 + 手写图表达（supervisor / swarm 均需自建） 自定义 Node + 自定义 reducer + 自定义 checkpointer 实现
CrewAI Crew / Agent / Task / Process / Flow Crew(checkpoint=True) → CheckpointConfig(location, on_events, provider=Json|Sqlite, max_checkpoints)，默认 task_completed 触发；Crew.from_checkpoint() 恢复。粒度是任务级，非 super-step 级 Sequential 与 Hierarchical（须给 manager_llm 或 manager_agent），Process 是 Enum @tool；Flow 的 @start / @listen / @router + self.state；四层 memory（short / long / entity / 外部）
AutoGen v0.4 Agent(RoutedAgent) / Team / Runtime / Topic。采用 actor 模型，拆三库：autogen-core / agentchat / ext save_state() / load_state()（agent 与 team 两级），默认实现存空状态，自定义 agent 须自行覆写 —— 「开发者自己管持久化」路线 RoundRobinGroupChat / SelectorGroupChat / Swarm / Magentic-One / GraphFlow autogen-ext；自定义 agent；可替换 Runtime（本地 / Orleans 分布式）
AG2 ConversableAgent / GroupChat / GroupChatManager（v0.2 语义的社区延续） 会话内 message history；官方称可持久化，独立分析指出 0.x 默认内存态、跨会话不保留（两方说法冲突，未下结论） GroupChat（selector 函数 + 全共享消息池）+ Swarm + beta network 的 Hub / TransitionGraph 自定义 selector；knowledge= / compact=；OpenTelemetry
OpenAI Swarm Agent / handoff（返回 Agent 的函数） / context_variables 无 —— stateless between calls，靠调用方把 Response 喂回去 handoff 网络（单一原语表达 agent / workflow / task） Python 函数即工具，自动生成 JSON Schema
OpenAI Agents SDK Agent / handoff / Session / SandboxAgent Sessions（SQLite / AsyncSQLite / Redis / SQLAlchemy / Dapr / Mongo / Encrypted / AdvancedSQLite）；run 前取历史、run 后写回；to_state() + interruptions + approve() 恢复 handoffs（专家接手当前 turn）vs agents as tools（Agent.as_tool()，manager 持有答案）；两者可混用 自定义 tool / guardrail / MCP server；Sandbox Capabilities（Filesystem / Shell / Memory / Skills / Compaction）+ Manifest / SandboxRunConfig
Claude Agent SDK Agent loop / Session / Subagent / Skill / Hook / Permission Session 自动落盘，continue / resume / fork；关键边界：Session 持久化对话，不是文件系统 —— 文件回滚另用 file checkpointing Subagent（上下文隔离、可并行、可限工具）+ Plugins Skills（SKILL.md）、Hooks、MCP、Permissions、Plugins
Google ADK Agent(LlmAgent) / Session / State / Event / Artifact / Runner SessionService（InMemory / Database / VertexAI）管会话生命周期；MemoryService 管跨会话检索；Artifacts 版本化二进制（session 级或 user 级，同名保存即产生新版本） sub_agents 层级 + 模板工作流 + ADK 2.0 graph / dynamic workflows + RoutedAgent（带失败回退） Tools、Skills、Plugins、Callbacks

9.4 协议

协议 解决的问题 所在层 与相邻层的关系
MCP 模型/agent 如何接入外部工具、数据与提示 垂直层（单个 agent ↔ 工具/上下文）。自身分 Data layer（JSON-RPC 2.0、发现、原语、通知）+ Transport layer（stdio / Streamable HTTP） A2A 官方定位其为「给 agent 深度」的互补下层；OpenAI Apps SDK 直接构建在其上；自身通过 extensions 向新层扩张（Tasks 长时任务句柄、Apps UI）；官方新增 skill 层协作页
A2A 不透明 agent 之间如何互相发现、协商与协作 水平层（agent ↔ agent）。HTTP(S) + JSON-RPC 2.0；Agent Card（发现）+ Task 生命周期 官方明确与 MCP 互补；提供跨层桥接：A2A Server 的 skill 可作为 MCP 兼容 resource 暴露
AGNTCY 跨厂商多智能体系统的发现、身份、消息、运行时与观测基础设施（Internet of Agents） 跨层栈，唯一把「本体/模式层」显式画进栈图：OASF（模式/本体）+ Agent Directory Service（发现）+ Identity（DID / 可验证凭据）+ SLIM（传输层，MLS 加密、pub/sub、流式）+ SHADI（运行时层，OS 沙箱）+ Observability / CSIT（横切）；ACP 提供调用远端 agent 的 OpenAPI REST 接口 让 A2A agent 与 MCP server 可被发现，用 SLIM 承载消息 —— 即位于二者之上/之间而非替代。2025-03 Cisco Outshift 开源，2025-07-29 捐给 Linux Foundation
OpenAI Apps SDK 让第三方 app 在 ChatGPT 内既有工具能力又有可交互 UI 应用/表现层，构建在 MCP 之上 复用 MCP 的 tools/resources 作骨架，用 _meta 扩展出 UI（ui.resourceUri / openai/outputTemplate / ui.domain / ui.csp / ui.visibility）与宿主 API window.openai

9.5 通用 Agent 产品的运行时沙箱

隔离粒度上高度一致：每任务/每会话一台隔离机器。Manus 官方措辞是「为每个任务分配的完全隔离云虚拟机」；Devin 文档写「每个 Devin session 跑在自己独立的机器上」；Operator system card 把「用虚拟机隔离环境」写成对开发者的推荐最佳实践。

技术底座趋同于 microVM 而非容器：Manus 用 Firecracker + E2B（AWS 新闻稿称约 125 ms 启动、5 MiB 内存；E2B 案例解释弃用 Docker 是因为其 10–20 s 启动且不是完整 OS）。

权限模型：Manus 讲得最细 —— Zero Trust + sandbox 内 root：用户与 agent 在 sandbox 内有完整控制权（可改系统文件、甚至格式化磁盘），但操作被限制在 sandbox 内，碰不到会话/账户数据，也影响不到服务稳定性；发生不可恢复错误时自动替换新 sandbox。

「产物 vs 中间态」的边界（对 pj0235 最有参考价值）：Manus 的沙箱生命周期是 Create → Sleep/Awake → Recycle/Recreate，回收后新建 sandbox 时只恢复 Manus artifacts、上传附件、Slides/WebDev 等重要文件；中间代码与临时文件不恢复。这实际上定义了一条边界：只有被标记为产物的东西才进持久层。

框架侧正在把它抽象化：Google ADK 的 Artifacts 是「命名 + 版本化的二进制数据」，作用域 session 级或 user 级，同名保存即产生新版本 —— 这是把「产物沉淀」做成一等对象的最完整实现。

一条重要边界提醒（Claude Agent SDK）：Session 持久化的是对话，不是文件系统；要快照与回滚 agent 改过的文件必须用另一套 file checkpointing。

另一条被低估的路线：OpenAI Operator 的无状态沙箱 —— API 文档明确提示「延续 response 并不会恢复浏览器会话、登录态或运行时变量」。即隔离性与可恢复性在此显式分开，与 Manus/Devin 那种「沙箱即持久工作区」的取向相反。

Devin 的部署形态划分（对企业交付有参考价值）：Enterprise Cloud（brain 与 devbox 都在 Cognition 多租户云，每 session 独立机器）vs Customer Dedicated Deployment（单租户 VPC，你方 VPC 通过 AWS Private Link 或 IPSec 隧道连接，Devbox 落在客户专属 VPC）。两个组件：The Brain（无状态的云服务）与 The Devbox（安全虚拟环境）。

10. pj0235 六层 vs 行业对照与建议

10.1 逐层对照

层 pj0235 代码现状（eai_agentplatform/backend-go/internal/） 行业对照
1 外部连接层 connectors/（api / core / packages / query / registry），仅 packages/kingdee 一个真实现，8 个静态 demo；无 connector_definition / connector_binding 表 全行业收敛到 MCP；国内还需 RPA 兜底
2 本体语义层 仅 ontology_binding_json 一个自由文本字段（skills/model/skill_definition.go、model/action_definition.go），运行时无人读取 选答题（六家五家没有），做了是护城河
3 总线编排层 无此包。最近似物是 specialists/runtime/task_runtime.go 的 ChooseTaskStrategy（二选一：UseAI 或单个 ConnectorKey）与 api/chat_message.go 的 TaskPlan/Step（仅响应结构体，步骤不入库不执行） 分裂中：图派 vs ReAct 派，未收敛，不必默认做 DAG
4 能力层 skill 已落地（skills/，22 个 packages）；action 部分（model/action_definition.go）；policy 缺失（只有 policy_refs_json 字符串数组，校验后从不解析执行） Skill 包已标准化（agentskills.io），方向对
5 对象层 三套并列表：specialist / skill_definition / xapp_definition（+ action_definition）。只做到命名规范统一（Key/Label/DisplayCode/EAILogicCode/Source/State/SortOrder，编码由 store/object_code.go 统一生成），无统一表、无统一 ID 行业也不统一（Dify 的 App/Workflow/Tool、Coze 的智能体/工作流/应用）
6 工作台治理层 有 task_record / task_run / task_artifact + api/task_runtime.go、my_task.go、workbench_overview.go；前端 views/workbench/。缺节点级执行表，缺消息持久化（对话不入库，frontend/src/store/taskRuntime.js 内存态） 缺的这两条全行业都有

补充事实：task_record 只有 SpecialistKey 一个绑定字段（即 SY24 §5.1 点名要修的「task 不能只挂一个 specialist_key」）；「任务挂多个对象」目前只存在于前端内存（store/taskRuntime.js 的 setTaskFocusedObject，无持久化）。

10.2 建议（按优先级）

① 给三张定义表补 draft/published + 版本快照（第 5 层）

  • 依据：全行业标配（n8n / Coze / Dify / Langflow / Relevance AI / 腾讯 ADP / 阿里百炼）。
  • 最小可行做法：加 version / publish_state 字段 + 一张 <object>_version 快照表；发布动作生成不可变快照，运行只读已发布版本。
  • 收益：解决「改完即生效」带来的不可追溯问题，且是后续 A/B、灰度的前提。

② 补节点级执行记录与消息持久化（第 6 层，本项目已有痛感）

  • 依据：节点级 run 表全行业都有（Dify WorkflowNodeExecutionModel、n8n runData[nodeName]、扣子 Span、华为 ListOpsTrace）；消息持久化全行业都有（Coze Conversation─Section─RunRecord─Message、飞书 aily Run+Conversation、Claude SDK session）。
  • 直接对症：本项目已知问题「task_run.status 恒为 done，步骤进度不在 run 表里，配对靠中文名、改名即静默断链」。
  • 可借鉴的字段设计：扣子罗盘的 TraceID / SpanID / ParentID / SpanType 四件套（能同时表达「谁发起 / 谁执行 / 父子关系」），恰是 SY24 §5.2 提出的同一诉求。

③ 认真评估连接层直接站到 MCP 上（第 1 层，生态账）

  • 依据：六家大厂全部原生支持 MCP；本项目「连接器」概念与 MCP server 几乎同构。
  • 需同时评估：RPA 兜底路径（国内 to B 绕不开），以及信创/私有化约束。

④ 对齐 agentskills.io 的 skill manifest 字段（第 4 层，低成本）

  • 依据：Agent Skills 已成为开放标准，且被 Claude Code / MCP 官方 / Google ADK / OpenAI Agents SDK 采纳。
  • 动作：核对本项目 skills/packages/ 的包结构，评估与 SKILL.md + manifest 字段的对齐成本；并评估技能定义是否全量进 prompt（若是，渐进式披露三级加载是已验证的解法）。

⑤ 第 3 层的补法需要单独拍板，不要默认做 DAG 画布

  • 依据：行业分裂为图派与 ReAct 派，本项目现有路线形态上更接近 Salesforce / ServiceNow 一派。
  • 若要复刻 ReAct 派的运行态语义，A2A 的 Task 生命周期是个好参照：中断态（input-required / auth-required）与终态（completed / canceled / rejected / failed），且终态后不可重启。

⑥ 第 2 层若要做，先做「小本体」

  • 依据：只有 Palantir 真做成运行时层，其机制可复刻 —— 把对象类型 + 动作类型映射成 agent 可用工具（对象=读、Action=写、Function=算）。本项目已有 ontology_binding_json 占位与 action_definition 表，具备最小落地条件。

11. 未查证 / 存疑项

明确未查到的项：

  • Dify、Coze、Flowise、Relevance AI、百炼、ADP、千帆、飞书 aily、盘古/AgentArts、元器 任何一家的「模型层 / 平台层 / 应用层」官方分层原话 —— 均未查到。国内分层原话全部来自研究侧文件（信通院 / 电信 / IDC / 华为云白皮书）。
  • 百度千帆 AppBuilder 的平台级评测、发布版本快照官方文档。
  • 飞书 aily 的评测集 / 评估器产品。
  • 腾讯元器的官方文档站 / 帮助中心 —— 检索中只出现开发者社区与百科文章；元器信息请按第三方可信度打折。
  • 影刀、实在智能的官方架构文档原文（影刀有官方飞书 wiki 但内容未能取到）。
  • Flowise 的草稿/发布版本机制与 Run 级实体（官方文档未给出 Run 级实体）。
  • Zapier Agents 的表结构与定义文件形态（闭源）。
  • Relevance AI 的官方分层与 DSL。
  • Coze 开源版与线上 SaaS 的表结构一致性证据。
  • 「专员 / 技能 / 应用」这个确切的三层命名 —— 未查到任何厂商使用这组词。最接近的三组是：来也技能层 / 执行层 / 控制平面、UniEmployee Employee → Workflow/SOP → Skill → Connector → Tool、社区 Tool → 数字员工 → Agent Platform。

存疑 / 说法冲突的项：

  1. Genspark —— 官方博客与官网对脚本抓取一律 403，无法从一手来源核实任何架构细节。二手来源一致描述为 MoA（Mixture-of-Agents）架构 + 30+ 模型 + 150+ 自研工具 + lead agent 协调多个专精 sub-agent，并预告按需创建 ephemeral agent（YAML 配置）；GAIA 自报 87.8%。以上全部为二手转述与厂商自报，未经独立验证，请勿当作已核实的架构事实使用。
  2. AG2 的持久化能力 —— ag2.ai 官方宣传「持久可恢复」与独立技术分析「0.x 默认内存态、跨会话不保留」直接冲突，本稿未替任何一方下结论。
  3. ACP 的详细机制（event stream、Threads、容器化暴露为 REST）来自二手分析文章，未在 agntcy/acp-spec 仓库 README 中逐条核实。
  4. Manus / E2B 的保留期数字不一致 —— Manus 官方博客写 Free 7 天 / Pro 21 天，E2B 客户案例写付费用户最长 14 天。已并列，未强行统一。
  5. Palantir Ontology 的 Semantic / Kinetic / Dynamic 三层 —— 中文圈常用口径，未在官方页面上核到原话，只算二手。

时效提醒：

  • MCP 的 Sampling 与 Logging 已在协议版本 2026-07-28 被标记为 deprecated；许多二手资料仍在写 sampling，引用时需注意。
  • Google ADK 2.0 中模板工作流已被 graph-based workflows 与 dynamic workflows 取代；旧的 google.github.io/adk-docs/agents/multi-agents/ 路径已失效，新域名为 adk.dev。
  • 扣子开发平台（低代码）不再向新注册用户开放，官方引导去扣子编程（code.coze.cn）。

12. 来源清单

12.1 编排与工作流型平台

12.2 大厂 Agent 平台

12.3 框架与通用 Agent 产品

12.4 协议

12.5 国内企业级平台

12.6 本仓库内相关文档

  • docs/01_System_Overall/SY21_统一角色技能动作架构.md —— 六层架构与命名收口
  • docs/01_System_Overall/SY22_角色技能应用统一任务架构.md —— 第五层升级为对象层、App 升为一级对象
  • docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY24_平台架构重思考.md —— 历史稿（4 层领域分层：定义/安装/实例/运行），结论已并入 SY21/SY22
  • docs/01_System_Overall/History_And_Retrospectives/2026-09-17_六层架构与三对象建设重点阶段性复盘.md —— 六层不变的正式收口
  • docs/02_Architecture/AR09_对象命名规范.md —— 对象命名规范（规范性文件）
  • docs/02_Architecture/AR10_应用可删除封装规范.md、docs/02_Architecture/AR11_技能专员连接器可删除封装规范.md —— 可删除封装规范
  • docs/09_Research/工作流画布交互研究.md —— 画布交互调研（Dify / n8n / Make / Zapier / Coze / Langflow）
  • docs/09_Research/01_Benchmarks_And_Mappings/艾翁界面源码深度扫描与办公智能体架构对比.md、docs/09_Research/01_Benchmarks_And_Mappings/微趣我的通用智能体调研与办公智能体架构对比.md —— 源码级 / 成品级对比
Reference in New Issue View Git Blame Copy Permalink