Manus 工程化实践研究综述（架构蓝图 · 落地清单 · 参考链接）

原创灵阙教研团队

A 推荐提升 | 约 19 分钟阅读更新于 2026-01-04

AI 导读

Manus 的工程化实践研究综述目标：把「Manus 作为通用 AI Agent 平台」的关键工程实践——上下文工程、沙箱与浏览器自动化、并行多智能体、工具/集成生态、API 与安全治理——整理为可落地的架构蓝图与清单。本文面向需要复刻/引入/对标类似能力的产品、平台与工程团队。版本：v1.0（研究版）生成日期：2026-01-04 语言：中文（含必要英文术语）范围：公开资料 +...

Manus 的工程化实践研究综述

目标：把「Manus 作为通用 AI Agent 平台」的关键工程实践——上下文工程、沙箱与浏览器自动化、并行多智能体、工具/集成生态、API 与安全治理——整理为可落地的架构蓝图与清单。本文面向需要复刻/引入/对标类似能力的产品、平台与工程团队。

版本：v1.0（研究版）生成日期：2026-01-04 语言：中文（含必要英文术语）范围：公开资料 + 用户提供材料

阅读提示： 这是一份“工程视角”的综述：先归纳 Manus 的系统性做法，再抽象成可复用的工程原则与实现模板。文末提供参考链接与落地检查表，便于直接开工。

0. 研究范围与方法

研究对象

本文的 “Manus” 指 manus.im 提供的通用 AI Agent 产品与其 API（open.manus.ai）。重点关注其“可执行”的平台化工程能力，而非单一模型效果。

资料来源

以官方博客、官方文档与 Manus API 文档为主；并把用户提供的《Claude Agentic SDK 智能体平台系统工程实施指南》作为“平台工程对照样例”（用于结构与治理层面的抽象）。

边界声明： 文中对 Manus 的“实现细节”只依据公开描述做工程抽象，不臆测其私有代码与内部架构。数字与指标若来自博客/文档，将在“参考链接”中标注出处，并建议以最新官方文档为准。

1. Manus 作为“云端可执行 Agent”的产品定义

传统对话式 AI 的核心是“回答”；而 Manus 更强调“执行”：给出目标后，Agent 在一个可操作的计算环境里调用工具、浏览网页、读写文件、产出可下载的结果。这种定义决定了它必须在工程层面同时解决：执行环境、工具生态、长链路可靠性与可观测/可控。

计算环境

会话背后是一台“云端虚拟机/沙箱”

把 agent loop 放进可执行环境：可运行命令、处理文件、安装依赖、保存中间产物（而不把所有信息塞进上下文）。

真实世界

浏览器不是“读网页”，而是“像人一样操作网页”

支持 Cloud Browser（云端隔离）与 Browser Operator（本地浏览器扩展），覆盖公开网页与需要登录的工作流。

平台化

集成能力决定上限：MCP、Slack、Gmail、Notion…

通过标准化连接器把外部系统变成可调用工具，让 Manus 成为“工作流编排层”。

为什么“工程化”在 Agent 产品里更关键？（展开）

Agent 的输入/输出比极端不均衡：多轮工具调用会让上下文迅速膨胀，导致成本、延迟与稳定性问题，需要专门的上下文工程与缓存策略。
副作用不可避免：一旦能“执行”，就涉及账号权限、数据安全、网络访问、写入外部系统等，需要治理（权限、审计、速率限制、沙箱隔离）。
可靠性来自闭环：错误、重试、恢复、回放不是“异常”，而是系统常态，需要可观测与状态机来驯化不确定性。

2. 总体架构蓝图：会话 · 沙箱 · 工具 · 观测

若把 Manus 抽象成工程系统，它更像“云端执行平台 + agent orchestration”。下面给出一个可复用的参考架构（与具体云厂商/语言无关）。

[User/UI] ──prompt/files──▶ [Orchestrator/API Gateway] │ │ │ (SSE/WebSocket events) │ create task / project / connectors ▼ ▼ [Timeline UI / Replay] [Task Store + State Machine] ──enqueue──▶ [Worker Pool] │ │ │ events │ alloc sandbox ▼ ▼ [Event Bus/Log] [Sandbox Runtime (VM/Container)] │ │ │ observability │ tool calls / fs / browser ▼ ▼ [Metrics/Tracing/Audit] [Tool Layer: MCP / Browser / Shell / Files] │ └──▶ [External Systems: Gmail/Notion/Slack/…]

2.1 分层职责（建议）

层	职责	工程要点（抓手）
Interface	输入输出、会话/项目、协作、可视化	流式事件（SSE/WS）、产物预览、权限提示、手动接管（Take Over）
Orchestration	任务创建、调度、状态机、配额	异步任务模型、幂等、重试、预算控制、队列/并发治理
Execution	沙箱内运行 Agent 与工具	资源隔离、文件系统、网络策略、工具权限、产物目录
Tool/Integration	把外部系统变成“可调用动作”	MCP/OAuth、工具 schema、错误语义、速率限制、审计
Governance & Observability	安全、合规、审计、可观测	事件协议、Trace/Span、Webhook 签名校验、RBAC、多租户

关键思想： 把“事件”当作一等产物（不仅是日志）。Agent 的计划、工具调用、错误、重试、文件产出都应该结构化发事件，才能支撑实时 UI、回放与审计。这一点也与许多 Agent 平台工程最佳实践相一致（见参考材料中的工程实施指南）。

3. 核心工程：Context Engineering（可扩展、可缓存、可恢复）

Manus 官方把大量迭代投入到“上下文工程”而不是训练端到端 agent 模型。这类实践的价值在于：它把 agent loop 的成本、延迟与稳定性，从“不可控”变成“可工程化优化”。

3.1 设计围绕 KV-Cache：稳定前缀 + 追加式上下文

为什么 KV-cache 是 agent 关键指标？

agent 往往经历大量“短输出（工具调用）+ 长输入（累计上下文）”的循环，导致 Prefill 远大于 Decode。因此缓存命中率直接决定 TTFT 与成本。

工程落点

把 system prompt、工具定义、协议头等尽量做成“稳定前缀”；执行过程只追加（append-only）新动作与观察；序列化必须确定性（例如 JSON key 顺序稳定）。

反直觉但很重要： 只要前缀有一个 token 变动（例如把“当前时间”写进 system prompt），缓存就从该处开始失效。对生产系统，这是实打实的成本与延迟放大器。

3.2 工具管理：Mask, Don’t Remove（不要动态删工具）

随着 MCP/连接器增多，工具数量会快速膨胀。直觉做法是“动态加载/卸载工具”以缩小 action space。但在 agent loop 里，这会破坏缓存前缀，并且让历史轨迹引用到“已不存在的工具定义”，引发模型困惑与 schema 违规。

可复用做法

工具定义保持稳定：不要在迭代中频繁增删工具描述。
用状态机/约束解码收缩 action space：根据上下文状态“掩蔽（mask）”不允许的工具，而不是移除定义。
工具命名分组：用一致前缀（如 browser_ / shell_）支持低成本的分组约束。

3.3 把文件系统当作“外置上下文”（可恢复压缩）

上下文窗口再大也会遇到：网页/文档 observation 过长、长上下文性能退化、传输与 prefilling 成本高等问题。 Manus 的一个关键抽象是：把文件系统视作“无限、持久、可操作”的外部记忆，让模型学会按需写入/读取文件。

压缩原则：可恢复（Restorable）

可以把网页正文从上下文丢掉，但必须保留 URL；可以省略文档全文，但要保留在沙箱中的路径。这样需要时可以重新抓取/重新读取，不做不可逆压缩。

工程实现建议

把“长 observation → 文件落盘 → 在上下文留指针”做成默认策略；同时提供文件检索/摘要工具，避免反复读全量。

3.4 通过“复述”操控注意力：todo.md 作为可执行计划

对长链路任务，目标容易被“淹没在上下文中间”。Manus 常见行为是生成并持续更新 todo.md，把全局计划不断“推到上下文末尾”，借此对抗 lost-in-the-middle。

3.5 保留错误轨迹：让模型从失败中更新策略

多步任务里，失败不是例外。一个工程化的观点是：不要把失败擦掉。失败的 action 与错误信息（甚至 stack trace）是模型修正后续决策的证据；清理痕迹反而更容易重复犯错。

3.6 避免“自我 few-shot”：引入结构化差异打破僵化模式

在重复批处理任务中，如果上下文充满相似的 action-observation 对，模型会机械模仿模式，产生漂移与幻觉。 Manus 的经验是引入小幅、可控的结构化差异（序列化模板、措辞、顺序微扰），提高鲁棒性。

把以上原则转成可执行的工程清单（展开）

上下文序列化：稳定前缀、追加式、确定性 JSON、显式 cache breakpoint（若框架需要）。
工具定义：静态 + 版本化；运行时用状态机/掩蔽来约束可用集合。
长 observation：默认落盘（文件/对象存储）+ 指针；必要时重放获取。
计划维持：todo.md/plan.md 作为“可见且可更新”的外部计划。
错误处理：失败事件结构化记录；支持“基于失败证据”的修复循环。
批处理去模式化：模板/顺序/措辞引入多样性；避免上下文变成单一示例集合。

4. 规模化并行：Wide Research 的多智能体范式

Wide Research 可以视作一种“系统级并行处理机制”：把一个高体量任务拆成大量子任务，并行分发给多个完整能力的子 agent，再汇总结果。官方描述其基础设施目标是把每个用户可用的计算规模提升到数量级。

与传统多智能体的差异

不是预设“经理/程序员/设计师”等固定角色，而是每个子 agent 都是通用能力实例。这有利于灵活拆解，但对调度、预算与结果一致性提出更高要求。

工程抽象：Map-Reduce 形态

Map：分解并行执行（检索/比对/抽取/验证）； Reduce：归并、去重、冲突消解、结构化输出。

4.1 可复用的“并行研究”执行协议

阶段	系统做什么	工程要点
Decompose	把“目标”拆成 N 个可并行子任务	子任务粒度；去重策略；输入模板；预算（token/时间/并发）
Dispatch	调度到子 agent 池并行运行	队列/限流；隔离沙箱；失败重试；分片与亲和性
Verify	对关键字段做交叉验证/一致性检查	多源对照；置信度；冲突标注；抽样复核
Synthesize	汇总成结构化报告/表格/产物	统一 schema；可追溯引用；导出（CSV/Sheets/Slides）

落地建议： 不要把 Wide Research 只当“多开几个 agent”。真正难点在“协作协议”：拆解模板、结果 schema、冲突处理、部分失败的可用性（partial success）以及预算控制。

5. Web 交互工程：Cloud Browser 与 Browser Operator

浏览器自动化是“通用 agent”走向生产的关键：大量真实工作流没有 API，且分布在登录态网站与各类 Web 应用中。 Manus 将其拆成两种环境：云端隔离浏览器与本地浏览器扩展，分别覆盖“可控一致”与“可信登录态”。

5.1 Cloud Browser（云端）

能力画像

在云端浏览器里像人一样点击、填表、抓取数据、跨页面完成流程。
允许用户在该环境里登录自己的账号，从而支持需要认证的操作。
遇到验证码/多因子等场景，提供“Take Over”让用户短暂接管后再交还。

安全与体验取舍

云端浏览器通常使用数据中心 IP，可能更易触发风控/验证码。
适合通用网页研究与规模化抽取；对敏感站点可切换到本地 Browser Operator。
建议：提前登录常用站点、对首次登录进行人工监控、定期清理会话。

5.2 Browser Operator（本地浏览器扩展）

Browser Operator 让 Manus 在你的本地浏览器会话中执行任务：复用你已有的登录态、受信任的 IP 与已打开的标签页，从而显著降低验证码/登录中断。设计重点是：用户授权、可中止、全程留痕。

工程要点（安全底线）： 本地扩展是高权限通道：必须做到“每次会话显式授权”、一键停止（例如关闭专用 tab）、细粒度操作日志与审计导出；并对敏感站点默认更谨慎。

如果你要实现类似能力：建议的技术拆分（展开）

控制面：扩展与服务端建立加密通道；会话授权与 TTL；可撤销。
数据面：只传“动作与必要 DOM 信息”，避免原始敏感数据全量外流；对表单输入可做脱敏/遮罩。
可观测：每一步操作结构化记录（URL、元素定位、动作、时间、结果）；支持回放与人工复核。

6. 工具与集成：MCP Connectors 与自建 MCP Server

工具生态决定 agent 的“可行动范围”。Manus 在文档中强调通过 MCP（Model Context Protocol）连接外部工具，使其成为工作流的编排层。对企业来说，最关键的是：把内部系统也接进来，并把权限、审计与性能当作第一优先级。

6.1 MCP Connectors（预置连接器）

定位：把常用 SaaS（Gmail、Google Calendar、Notion、Stripe、HubSpot、Slack 等）变成可调用动作；减少复制粘贴与跨应用跳转。
接入方式：OAuth 2.0 授权；用户可控权限范围；在 prompt 中直接提及应用即可触发。
强项：跨应用多步骤工作流（如 Notion → Calendar；Gmail 附件分析 → 汇总报告）。

6.2 Custom MCP Servers（自建连接器：连接内部系统）

自建 MCP Server 的本质是一个轻量服务：在你控制的网络里，把“内部系统/私有 API/业务逻辑”封装成一组工具与资源，提供给 Manus 调用。 Manus 文档给出了架构、接入步骤与安全注意事项，可作为企业落地的直接参考。

工具设计最佳实践（浓缩版）

工具要“小而清晰”：一个动作一个 tool；避免“万能工具”。
描述要“可判定”：写清楚什么时候该用、参数语义、失败模式。
长耗时用异步：返回 task_id，再提供 status 工具查询。
错误要可操作：返回可修复的信息（而不是模糊的 500）。

安全治理（必须项）

认证：API key / OAuth / mTLS；密钥轮换。
授权：RBAC/ABAC；按用户映射权限；全链路审计。
传输：HTTPS；敏感字段加密与脱敏；速率限制。
网络：部署在受控网段；白名单/防火墙；必要时 VPN。

落地建议： 把 MCP Server 当成“内部微服务”来做：版本化、自动化测试、监控告警、灰度发布、回滚机制，一个都不能少。

7. 开发者接口：异步任务 · 文件 · Webhook 安全

Manus API（open.manus.ai）把 agent 执行抽象成“异步任务（task）”：你发起请求，系统后台运行并提供轮询或 webhook 通知。这一模型天然适配长链路、多工具、需要等待外部系统的工作流。

7.1 异步任务模型（状态机）

典型状态：running（执行中）、 pending（等待用户输入/交互）、 completed（完成）、 error（失败）。你可以轮询任务状态，或用 webhook 接收生命周期事件。

7.2 OpenAI SDK 兼容（Responses API 形态）

官方文档提供了一种实用的兼容策略：用 OpenAI Python SDK 的 client，把 base_url 指向 Manus API，并在自定义 header 中携带 Manus 的 API key。

复制# Python（示例，按官方文档思路整理）
from openai import OpenAI
import time

client = OpenAI(
  base_url="https://api.manus.im",
  api_key="placeholder",
  default_headers={"API_KEY": "YOUR_MANUS_API_KEY"},
)

# 1) 创建异步任务（agent 模式）
resp = client.responses.create(
  input=[{
    "role": "user",
    "content": [{"type": "input_text", "text": "请汇总近一年 AIGC 竞品趋势并输出表格"}]
  }],
  extra_body={"task_mode": "agent", "agent_profile": "manus-1.6"},
)

task_id = resp.id

# 2) 轮询直到完成（生产建议改用 webhook）
while True:
  cur = client.responses.retrieve(response_id=task_id)
  if cur.status in ("completed", "error", "pending"):
    break
  time.sleep(5)

print(cur.status)
# 完成后：cur.output 里包含多轮消息与产出文件（若有）

文件上传注意： Manus API 采用“先创建文件记录 → 获取预签名上传 URL → 再 PUT 上传”的两步；预签名 URL 有短期过期时间。同时，文档也提示上传文件会在一定时间后自动删除——工程上要设计“及时引用/持久化归档”的策略。

7.3 Webhook 安全：签名校验 + 防重放

Webhook 是把异步任务接进企业系统的关键，但也最容易被伪造请求攻击。Manus API 文档提供了 RSA-SHA256 签名验证机制，并建议校验时间戳以防重放。

从请求头读取 X-Webhook-Signature 与 X-Webhook-Timestamp。
按文档规则拼接待签名内容并 SHA256；用官方 public key 做 RSA 验签。
时间戳窗口（例如 5 分钟）外拒绝，以降低重放风险。
对公钥做缓存，不要每次都拉取。

8. “Manus-like 平台”落地路线图（可直接复用）

下面给出一套“从 0 到 1”落地路径：既吸收 Manus 的公开经验，也结合常见 agent 平台工程做法（参考用户提供的工程实施指南）。你可以把它当成启动一个内部项目的初始蓝图。

8.1 第一阶段：可控 MVP（2–4 周）

最小闭环

任务 API：create → running → completed/error 状态机。
沙箱：每任务容器/微 VM；只读输入卷 + 输出目录；CPU/内存/时长配额。
工具：文件读写 + HTTP fetch（白名单）+ 基础浏览（可选）。
事件：至少记录 plan/tool/file/error 四类事件，可回放。

Context 工程先行

系统前缀稳定；上下文追加式；确定性序列化。
长 observation 落盘并只留指针。
todo.md 机制：计划持续复述到末尾。
错误不擦除：把失败当作学习信号。

8.2 第二阶段：可用性与生态（4–8 周）

工具生态

MCP client + 预置连接器（OAuth）。
自建 MCP Server 模板与脚手架。
工具版本化、权限化、审计化。

并行与队列

Wide Research 风格的并行分发与汇总。
预算控制：并发上限、token 上限、时间上限。
部分成功：允许返回“已完成部分 + 失败列表”。

可观测与治理

Trace/Span：每个工具调用一个 span。
安全：凭证短期化、网络白名单、输出脱敏。
Webhook：验签 + 重放防护。

8.3 第三阶段：团队协作与产品化（持续）

Projects/Workspace：把 master instruction、知识库、工具集合做成可复用配置，支持团队协作与权限。
浏览器体系：云端浏览器（隔离一致）+ 本地浏览器扩展（可信登录态）。
质量门禁：基于场景的回归集、工具成功率与恢复率指标；上线前自动评测。
合规：数据分级、审计留存策略、组织级策略（如禁止访问某些域/工具）。

最容易被低估的成本： 不是“让模型会用工具”，而是“让工具使用在真实世界里可控、可回放、可审计、可扩展、可运维”。 Agent 平台的工程壁垒通常在治理与观测，而不是 prompt。

9. 反模式与常见踩坑

上下文与缓存

在 system prompt 里拼接时间戳/随机数，导致 KV-cache 命中率暴跌。
序列化不确定（JSON key 顺序漂移），看似无害但持续破坏缓存。
把网页全文/大 PDF 直接塞上下文，造成成本爆炸与性能退化。

工具与执行

运行中动态删除工具定义：历史轨迹引用失效、模型 schema 违规。
工具“万能化”：一个 tool 做太多事，难以约束与复用。
错误被“擦掉”：重试成功但丢失证据，导致模型重复踩坑。

安全与权限

沙箱可出网 + 可执行任意代码 + 可访问敏感数据，没有代理/白名单/审计。
把长期凭证写入沙箱文件或日志；缺乏轮换与最小权限。
Webhook 不验签：任何人都能伪造“任务完成”事件。

并行与质量

只做并行，不做汇总协议：结果难以统一、冲突不可控。
没有预算：并发无限开，成本与外部 API 限流直接爆炸。
缺乏场景回归：线上一改 prompt 就劣化一堆任务。

附录：模板与清单

A. 事件协议（建议）

建议把 agent 的关键动作统一成事件流，既支持实时 UI，也支持审计与回放。下面是一个“最小可用”的事件模型示例。

复制{
  "event_id": "evt_20260104_0001",
  "ts": "2026-01-04T03:45:00Z",
  "session_id": "sess_xxx",
  "task_id": "task_xxx",
  "type": "tool.finished", 
  "actor": "agent", 
  "payload": {
    "tool_name": "browser_click",
    "input": {"selector": "#submit"},
    "output": {"ok": true},
    "latency_ms": 842
  },
  "trace": {
    "trace_id": "trace_xxx",
    "span_id": "span_xxx",
    "parent_span_id": "span_parent"
  },
  "security": {
    "tenant_id": "org_abc",
    "user_id": "user_123",
    "policy_tags": ["prod", "pii:no"]
  }
}

事件类型建议： task.created, plan.generated, tool.started/tool.finished, artifact.created, task.completed/task.failed, handoff.requested（需要用户接管）等。

B. Tool / MCP 设计模板

一个好工具要“可判定、可约束、可审计”。下面给出工具定义的写法模板（适用于 MCP 或自研 tool schema）。

复制name: "crm_update_deal_stage"
description: >
  Update the stage of a deal in the internal CRM.
  Use when the user explicitly asks to move a deal to a new stage
  and you already have a valid deal_id.
inputs:
  deal_id: string (required) - Stable CRM identifier
  stage: enum["lead","qualified","proposal","won","lost"] (required)
  note: string (optional) - Short explanation to append to the activity log
outputs:
  ok: boolean
  updated_at: string (ISO8601)
  audit_id: string
errors:
  - code: "NOT_FOUND" - deal_id not exists
  - code: "FORBIDDEN" - user has no permission
  - code: "RATE_LIMITED" - retry_after_ms provided
  - code: "VALIDATION_ERROR" - input invalid
security:
  auth: "mTLS + user token"
  rbac: ["sales:write"]
  pii: "no"
idempotency:
  key: "deal_id + stage + note_hash"

建议： 工具要支持幂等（尤其是写操作）；对长任务提供“异步 + 查询状态”模式；所有写操作必须带审计 ID。

C. Context 序列化与缓存策略（示例）

目标：稳定前缀、确定性序列化、追加式历史、长 observation 外置。下面给出一套可实现的伪代码。

复制// Pseudocode
prefix = stable_system_prompt + stable_tool_definitions + stable_protocol_header

history = []  // append-only: [{action}, {observation}, ...]
fs_index = {} // pointers: {id: {path/url, checksum, kind}}

function append_action(action):
  history.push({type:"action", ...action})

function append_observation(obs):
  if obs.size > OBS_THRESHOLD:
     ref = write_to_fs(obs)        // file path in sandbox
     fs_index[ref.id] = ref.meta
     history.push({type:"observation_ref", ref_id: ref.id, hint: ref.hint})
  else:
     history.push({type:"observation", ...obs})

function serialize_context():
  return prefix + deterministic_json(history) + deterministic_json(fs_index.summary())

// Note: keep prefix stable; deterministic_json must sort keys recursively.

实现提示： deterministic_json 需要“递归排序 key”；并发环境下要保证路由一致性（session affinity）以提升 prefix cache 命中。

D. 评测与观测指标（建议）

在线指标（生产）

任务成功率 / 一次成功率（one-shot）
工具调用成功率、重试次数、恢复成功率
平均步骤数、平均工具调用数、平均运行时长
KV-cache 命中率、TTFT、token 成本（prefill vs decode）
高风险动作占比（写操作/外部网络/敏感域）

离线评测（回归）

场景集：文档分析、网页流程、批处理、跨应用工作流
对照：prompt/工具版本变更前后差异
失败分类：schema 违规、工具错误、规划漂移、信息缺失
可解释性：失败证据链（事件 + 文件 + 截图/URL）

关键观点： 对 agent 来说，“能从失败中恢复”往往比“理想条件下的成功率”更能反映真实能力。评测要覆盖错误注入与恢复路径。

参考链接（公开资料）

下面列出本文主要参考的公开资料（优先官方来源）。请以最新官方文档为准。

Manus Docs · Welcome：https://manus.im/docs/introduction/welcome
Manus Blog · Context Engineering for AI Agents：https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
Manus Blog · Introducing Wide Research：https://manus.im/blog/introducing-wide-research
Manus Docs · Wide Research：https://manus.im/docs/features/wide-research
Manus Docs · Cloud Browser：https://manus.im/docs/features/cloud-browser
Manus Docs · Browser Operator：https://manus.im/docs/features/browser-operator
Manus Blog · Manus Browser Operator：https://manus.im/blog/manus-browser-operator
Manus Docs · MCP Connectors：https://manus.im/docs/integrations/mcp-connectors
Manus Docs · Custom MCP Servers：https://manus.im/docs/integrations/custom-mcp
Manus API · OpenAI SDK Compatibility：https://open.manus.ai/docs/openai-compatibility
Manus API · Webhooks Security：https://open.manus.ai/docs/webhooks/security
Manus Blog · Introducing Manus Projects：https://manus.im/blog/manus-projects
Manus Blog · Manus 1.6 Release (Max)：https://manus.im/blog/manus-max-release
用户提供材料：《Claude Agentic SDK 智能体平台系统工程实施指南》（用于平台工程对照与结构抽象）