通用 Agent 平台：构建可复用的交付能力

01 · 开篇：从一次交付，到一个通用平台

本章要回答：一次交付怎样被拆成可配置的产品能力，并最终让不同的人、不同的项目都能重复使用。

阿明第一次接到认证项目时，只需要把事情做成：读懂仓库、补齐注册和登录、接入页面、运行测试，再把改动交给团队。现有 Agent 平台帮他完成了大量工作，但真正决定结果的内容散落在他的操作顺序、临时提示和判断里。比如，他知道退出接口返回 200 还不够，还要确认旧凭据再次访问时确实得到 401；他知道测试服务重启后要重新检查环境；他也知道代码写入一半中断时，应该先读取当前差异，再继续执行。

项目第二次发生时，问题就从“能不能做成”变成了“别人能不能稳定做成”。小林接手同一个仓库，却不知道哪些事实已经确认、哪些命令可以执行、哪些动作必须审批，也看不见阿明判断 A4 通过时依据的证据。团队只能把记忆重新写进提示词，再靠另一次对话补齐遗漏。个人经验可以救急，却不能天然成为产品能力。

因此，本章的起点不是再造一个聊天框，而是追问：一次成功交付中，哪些判断、资料、动作、状态和证据必须被平台保存、约束和复用？答案会落到一组可实现的模块：工作空间承载边界，Agent 配置承载职责，任务契约承载目标，Context 承载事实，Graph 组织依赖，工具网关控制动作，运行中心保存状态，验证中心判断完成，资产中心沉淀下一次交付。

图 1 · 从一次交付经验到通用平台能力

flowchart LR U["用户提交委托\n目标与约束"] --> F["平台补齐事实\n项目、环境、规则"] F --> X["平台组织执行\nAgent、Graph、工具"] X --> V["平台返回证据\n验证、状态、交付物"] V --> A["平台沉淀资产\n模板、策略、评测"] A --> N["下一位用户\n复用并调整"] N --> U

01.1 先看清变化：从“我会做”到“平台能让别人做”

个人使用 Agent 时，交付链条可以藏在一次对话里；通用平台必须把链条显式化。用户要能看见自己提交了什么、平台读取了哪些事实、Agent 获得了哪些权限、任务当前卡在哪里，以及结果由哪条证据支持。只有这些信息有稳定的对象和界面，系统才可能被审计、恢复和复用。

一次性使用	通用 Agent 平台
目标留在对话上下文中	目标形成有版本的 Task Contract，可追踪变更
事实靠用户临时粘贴	Project 与 Context Center 注册来源、权限、版本和新鲜度
模型建议直接触发动作	Graph、Tool Gateway 和 Policy 决定何时、能否、以什么范围执行
失败后重新讲一遍背景	Run、Event、Checkpoint 支持暂停、恢复、重试和人工接管
结果停在聊天记录里	Evidence、Artifact、Verifier 和 Template 让交付可核对、可复用

01.2 本文要带读者完成什么

本文会沿着一条实际用户路径展开：先创建工作空间并接入项目，再选择或配置 Agent，提交任务并确认验收契约；随后平台准备上下文，生成 Graph，调用受控工具运行；遇到失败时保存检查点并恢复，最后用证据完成验收，并把稳定的配置沉淀为模板。每一章都同时回答三个问题：用户在页面上做什么，平台需要哪些功能模块，后台如何把模块连成可运行的系统。

贯穿案例：认证项目只承担“验证平台能力”的角色。它会验证项目接入、Agent 配置、任务契约、Graph 编排、工具权限、运行恢复、结果验收和模板复用；如果把认证任务替换成数据迁移、报表生成或接口改造，平台的核心对象和执行链仍然成立。

思考：平台化不是把一次提示词复制成一个按钮，而是把交付中依赖个人记忆的判断，变成可配置的对象、可观察的状态、可验证的证据和可复用的资产。

02 · 平台目标：通用 Agent 平台到底要解决什么

本章要回答：平台为谁服务、承诺什么结果、第一版做到什么程度，以及怎样判断目标已经达成。

“通用”不是把更多模型、工具和按钮堆在一起，而是让一套稳定的交付机制适用于多个项目。平台要解决的核心问题是：用户只说明要交付什么，系统就能在明确边界内取得事实、安排执行、处理异常、给出证据，并让下一次任务复用已经验证过的配置。

认证项目可以帮助我们验证这个目标。用户要补齐注册、登录、退出和页面接入，平台需要知道仓库和环境，选择合适的 Agent，生成任务计划，允许它读取和修改测试目录，禁止越权操作，并用“退出后旧凭据必须返回 401”等验收条件判断结果。换成数据迁移或报表生成，具体工具会变化，但目标确认、事实准备、受控执行和证据验收仍然存在。

02.1 平台的核心承诺

让授权用户能够：
  选择或配置一个有明确职责的 Agent
  接入项目、环境、规则和上下文来源
  把自然语言委托变成可确认的任务契约
  查看计划、依赖、权限和预期交付物
  在受控范围内连续执行工具动作
  观察运行状态、日志、事件和检查点
  在失败、等待或审批时恢复或接管
  用验收规则和证据判断是否完成
  将稳定的任务配置沉淀为模板并复用

这组承诺把平台从“模型调用服务”区分出来。模型只负责提出判断和动作建议，平台负责确认目标、补齐事实、约束权限、保存状态、执行工具和核对结果。平台可以允许模型犯错，但不能让错误无记录地改变项目，也不能把一段未经验证的回答包装成交付。

平台承诺	用户能看到的结果	后台必须提供
目标可确认	任务契约、范围、非目标和验收条件清楚	Task / Contract 版本与差异记录
执行可控制	知道 Agent 能读取、修改和调用什么	Tool Gateway、Policy、审批和审计
过程可观察	看到当前节点、等待原因和下一步	Run、Event、Graph 状态和日志
结果可验证	每个结论都有测试、差异或外部检查证据	Verifier、Evidence 和 Delivery
失败可恢复	中断后能继续、重试、回滚或交给人处理	Checkpoint、Retry、Pause、Resume、Handoff
能力可复用	下一次任务可以从模板开始并比较版本	Asset、Template、评测和发布机制

02.2 平台服务哪些角色

同一个平台会被不同角色以不同方式使用。角色划分不是为了增加组织层级，而是为了明确谁可以配置、谁可以执行、谁可以批准、谁对结果负责。

角色	主要任务	需要的平台能力	认证案例中的动作
任务用户	提交目标、查看进度、接收交付	Task Center、状态、证据和交付页	创建认证任务并复查 A1–A5
Agent 构建者	配置职责、模型、工具、上下文和输出契约	Agent Studio、版本、样例和评测	发布认证交付 Agent
项目管理员	接入仓库、环境、凭据和项目规则	Project Center、Credential、Policy	绑定测试分支和本地服务
平台运营者	观察成本、失败率、耗时和模板复用	Runtime Center、指标、审计和告警	比较 R1、R2、R3 三次运行
Reviewer	审批高风险动作、接管异常、确认交付	Decision、Handoff、Evidence	确认退出探针和最终说明

02.3 第一版平台的范围与非目标

第一版应选择一类可以被验证的交付任务，先把闭环做完整，再扩展行业和工具。本文选择“已有项目中的受控代码交付”作为范围：任务有明确仓库和环境，Agent 需要读取、修改、测试和提交说明，关键结果可以用自动化检查或人工复核确认。

• 不覆盖所有行业、语言、模型和部署环境。
• 不让 Agent 无限自主运行，长任务必须有预算、超时和停止条件。
• 不默认接管生产环境和生产密钥，敏感动作需要显式授权或审批。
• 不把所有工具开放给所有用户，工具访问必须绑定 Project、Environment 和 Policy。
• 不把一次案例的个人经验直接包装成通用能力，模板必须经过样例运行和验收。
• 不把“模型说完成了”当成完成，交付必须带有可核对的证据。

这些边界会直接决定后续设计：权限中心要能拒绝生产写入，Agent 配置要声明适用项目，运行中心要支持暂停和恢复，验收中心要允许证据否决模型结论，资产中心要记录模板的版本和适用范围。

02.4 怎样判断平台目标达成

平台目标不能只用“页面做出来了”验收，而要用同一套任务换用户、换项目或换 Agent 版本进行复测。认证案例的最低验收可以写成四个问题：

1. 换人：没有阿明的口头说明，小林能否根据平台记录启动并完成任务？
2. 换环境：从开发环境切到测试环境后，平台是否重新计算上下文、凭据和权限？
3. 换结果：当退出接口表面返回 200 但旧凭据仍有效时，验证器能否拒绝交付？
4. 换运行：在写入代码后中断，平台能否从检查点恢复，并保留前一次失败的证据？

如果这些问题只能依靠某个人记得“应该怎么做”，平台仍然是一次性工具；如果它们都有稳定对象、明确状态和可追溯证据，才开始具备通用交付能力。

本章产物：平台定位、核心承诺、角色模型、第一版范围、非目标，以及一组可以在认证案例中复测的验收问题。

03 · 用户如何使用通用 Agent 平台

本章要回答：用户从第一次进入平台到收到交付，怎样走完一条连续、可理解、可中断的使用路径。

用户不应该先学习平台内部的对象名，才能完成任务。平台的默认入口应是“我要交付什么”，再根据任务逐步呈现项目、Agent、权限、计划和验收信息。复杂能力藏在流程背后，但关键决定必须在用户看得懂的地方出现。

图 2 · 用户从委托到交付的主路径

flowchart LR A["提交目标"] --> B["选择项目与环境"] --> C["选择 Agent"] --> D["确认契约"] --> E["查看计划与权限"] --> F["启动 Run"] --> G["处理等待或失败"] --> H["复查证据"] --> I["接收交付"]

03.1 用户看到的十个动作

1. 创建工作空间：选择个人或团队归属，确定任务、资料和资产的隔离边界。
2. 接入项目：连接仓库、分支、环境、规则和可用凭据。
3. 选择 Agent：从模板选择，或查看职责、工具和适用范围后配置新的 Agent。
4. 创建任务：说明目标、约束、非目标、期望交付物和时间要求。
5. 确认契约：检查平台解析出的范围、验收条件和权限，必要时修改。
6. 查看计划：阅读 Graph 节点、依赖、风险和人工介入点。
7. 启动运行：授权平台按当前版本的 Contract、Graph 和 Policy 执行。
8. 处理等待：补充事实、审批动作、解决冲突，或把任务交给 Reviewer。
9. 复查证据：查看差异、测试、环境、日志和未决事项，而不是只看一句总结。
10. 接收交付：接受、返工、阻塞或将稳定配置保存为模板。

03.2 同一条路径如何映射到产品模块

用户阶段	用户关心的问题	主要模块
准备	任务属于哪个团队、项目和环境？	Workspace / Project Center
委托	平台到底理解了什么？	Task Center / Contract
执行	Agent 要做什么，能做什么？	Agent Studio / Graph / Tool Gateway
观察	现在进行到哪里，为什么等待？	Runtime Center / Event Stream
验收	结果凭什么算完成？	Verification Center / Evidence
复用	下一次能否少做重复配置？	Asset & Template Center

03.3 认证案例怎样走过这条路径

用户动作	认证案例	平台返回
接入项目	后台仓库、测试分支、本地服务	Project Profile 与环境状态
选择 Agent	认证交付 Agent	职责、工具、预算和版本
创建任务	补齐注册、登录、退出和页面	Contract 草稿和 A1–A5 验收
查看计划	T01–T06 节点及失败出口	Graph 依赖、权限和风险
处理失败	A4 失败后修复并重验	Run、Checkpoint 和差异
接收交付	R3 的代码、测试、说明和证据	Delivery 与可复用模板

思考：好的平台不是让用户点击更多按钮，而是让用户只提交一次清楚委托，并在真正需要决定的地方看到一个明确问题和足够证据。

04 · 工作空间与项目：平台从哪里开始

本章要回答：项目、环境、规则和权限怎样成为 Agent 可安全工作的基础容器。

任务不能从一段孤立的文本开始。平台必须先知道任务属于谁、代码和资料在哪里、当前使用哪个版本、允许连接什么环境，以及哪些规则优先于模型建议。Workspace 和 Project 就是这层事实与权限边界。

04.1 基础对象如何分工

对象	解决的问题	认证案例
Organization	谁拥有团队、成员和治理规则	认证项目所属团队
Workspace	哪些任务、Agent、运行和资产可以一起工作	认证交付工作区
Project	代码、资料、分支和项目规则在哪里	后台认证仓库
Environment	本次执行连接开发、测试还是生产	本地测试服务
Credential	如何安全引用账号、令牌和服务凭据	测试用户和服务凭据
Policy	哪些动作、路径、预算和风险被允许	禁止生产写入

04.2 用户接入项目时发生什么

图 3 · Project Center 生成项目工作画像

flowchart TD A["选择 Workspace"] --> B["连接仓库或目录"] --> C["选择 Branch 与 Environment"] --> D["读取规则、依赖和测试入口"] --> E["绑定 Credential 引用"] --> F["计算 Policy"] --> G["生成 Project Profile"]

Project Profile 不只是仓库 URL。它至少要保存代码版本、分支、运行入口、测试命令、规则来源、可访问目录、环境标签、凭据引用和最后探测时间。切换分支或环境时，平台重新计算 Context Package 和 Policy，避免 Agent 继续使用旧事实。

04.3 隔离、共享与变更

不同 Workspace 默认隔离任务、运行和敏感资料；同一 Workspace 可以共享 Agent、验收模板和项目规则，但共享资产不能扩大访问权限。用户能看到什么、Agent 能读取什么、工具能写入什么，分别由成员角色、Project Policy 和 Environment Policy 共同决定。

项目配置发生变化时，平台应生成变更事件并标记受影响的任务。比如认证仓库切换分支后，旧 Run 仍保留原证据，新 Run 必须绑定新的 commit、环境探测和权限快照。

本章产物：Workspace 模型、Project Profile、环境配置、凭据引用、项目规则、权限隔离和项目变更记录。

05 · Agent 配置：如何从模型变成可使用的 Agent

本章要回答：平台如何把模型、提示、上下文、工具、策略、Graph、验证器和输出契约组合成一个可使用的 Agent。

模型只是推理引擎，不是完整的 Agent。一个能被团队复用的 Agent 必须有明确职责、输入来源、工具边界、执行流程、验收方式和版本记录。配置的目标是把“会回答”变成“能在边界内完成一类工作”。

05.1 Agent 的配置合同

Agent Version
= Model + Prompt
+ Context Sources + Tools
+ Policy + Graph
+ Verifier + Output Contract
+ Budget + Version

配置项	用户要回答什么	认证交付 Agent
职责	为谁解决哪类问题，什么情况不适用	已有项目的认证交付
模型与提示	如何分析任务、何时停下并请求确认	代码分析和受控执行
上下文源	从哪些项目、规则和知识取事实	仓库、Session 规则、测试环境
工具与 Policy	可以读、写、测试和访问什么	测试目录，禁止生产操作
Graph 与 Verifier	如何分步执行，如何判断每步完成	T01–T06、A1–A5
输出契约	交付必须包含哪些结果和证据	差异、测试、说明、Evidence

05.2 Agent Studio 的配置流程

1. 填写职责、适用项目和不适用场景。
2. 选择模型、参数、上下文预算、超时和费用上限。
3. 绑定 Context Source，并指定哪些资料必须引用来源。
4. 选择工具，配置路径、环境、审批和风险策略。
5. 连接 Graph、Verifier 与 Output Contract。
6. 用认证任务和边界样例运行评测，记录失败原因。
7. 发布新版本，保留草稿、评测、回滚和停用入口。

每次模型、Prompt、工具、Graph、Policy 或 Verifier 变化，都必须产生新的 Agent Version。历史 Run 绑定自己的版本，不能因为 Agent 后来发布新配置而改变过去的执行含义。

本章产物：Agent Schema、Agent Studio、职责说明、版本管理、评测样例、发布和回滚机制。

06 · 任务与契约：用户如何向 Agent 发出委托

本章要回答：平台如何把自然语言委托变成双方确认过的目标、范围、验收和交付契约。

任务创建不是把一段话塞进聊天框，而是让用户确认平台理解了什么。平台可以先解析自然语言，再生成 Contract 草稿；用户确认后才允许进入执行，避免 Agent 在错误目标上连续工作。

06.1 Task Center 要收集什么

字段	用户填写或确认	认证案例
目标	希望交付什么可观察结果	补齐认证并接入页面
Project / Environment	在哪个项目、分支和环境执行	后台仓库测试分支
约束	必须遵守哪些已有规则	沿用 Session 和错误响应
Non-goal	明确本次不做什么	不做 OAuth、不碰生产密钥
Acceptance	怎样判断目标完成	A1–A5
Execution Scope	工具、目录、预算和审批	测试目录和测试服务
Output	最终交回哪些结果、证据和限制	差异、测试、说明和 Evidence

06.2 从自然语言到 Contract

图 4 · Task 创建到执行契约确认

flowchart LR U["自然语言委托"] --> P["解析目标、项目、约束"] --> C["生成 Contract 草稿"] --> R["用户确认范围与验收"] --> G["生成可执行 Graph"] --> X["允许启动 Run"] C --> Q["缺少事实或权限"] --> U R --> D["需要决策"] --> U

解析器可以帮助用户补全字段，但不能替用户默默扩大范围。平台要把推断出的内容标为“待确认”，把用户原话、平台推断、用户修改和最终版本都保存下来。

06.3 变更、拒绝与版本

目标、验收或权限发生变化时，平台创建新的 Contract Version，展示差异并标记受影响的 Graph 节点。已经完成的节点是否需要重跑，由影响关系决定；不能通过编辑原文本让旧证据看起来像是针对新目标产生的。

本章产物：Task Center、Contract Schema、Acceptance 模板、范围变更、Decision 记录和任务输出契约。

07 · 上下文与知识：Agent 如何取得项目事实

本章要回答：平台如何按任务和节点构建有来源、有权限、有新鲜度的 Context Package。

Agent 不会因为“知道项目名称”就自动知道项目事实。平台要管理的是文件、规则、知识、历史运行、环境状态和外部资料的来源、权限、版本与新鲜度，并在需要时把相关内容送到当前节点。

07.1 Context Center 管理哪些资料

资料类型	来源	需要记录的元数据	认证案例
项目文件	仓库、分支和工作区	路径、commit、更新时间	认证路由和 Session 代码
项目规则	规则文件、README、配置	来源、优先级、适用范围	错误响应和启动规则
知识资料	知识库、规范、接口说明	权限、版本、有效期	认证验收约定
运行事实	Tool Call、Observation、Check	Run、节点、时间、环境	退出探针结果
环境状态	服务、依赖、测试数据	探测时间、健康状态	本地测试服务状态

07.2 Context Builder 怎样按需组装

Context Builder 接收 Contract、Project Profile 和当前 Graph 节点，先根据权限筛选来源，再按相关性和预算取资料，最后生成带引用的 Context Package。它不会把整个仓库或所有历史对话一次性塞给模型。

图 5 · 当前节点的上下文组装

flowchart TD A["Contract + Project + Node"] --> B["选择允许的来源"] --> C["检索相关事实"] --> D["过滤过期与敏感内容"] --> E["压缩并附来源"] --> F["Context Package"] --> G["Agent 推理"] G --> H["产生新 Observation"] --> D

例如认证任务 T04 只需要退出路由、Session 配置、`/me` 实现、A4 条件、原凭据请求和测试环境状态。无关的页面样式和过期摘要不应默认进入上下文。用户应能查看 Agent 使用了哪些资料、哪些资料无权限、哪些资料已过期。

07.3 上下文的治理规则

• 事实、假设、规则、摘要和决定分开存储。
• 每项资料保留来源、版本、时间、权限和适用环境。
• 代码、分支、环境或 Contract 变化时触发刷新。
• 敏感资料使用凭据引用或脱敏结果，而不是原文直接注入。
• 无法追溯的摘要只能作为线索，不能直接成为验收证据。

本章产物：Context Center、Source Registry、Context Package、资料权限、新鲜度、刷新和引用机制。

08 · 工作流与 Graph：平台如何组织复杂任务

本章要回答：平台如何用节点、依赖、分支、循环、审批和失败出口，把长任务变成可推进的执行图。

Graph 是通用平台的编排模块。它不是只给工程师看的流程图，而是定义任务可以怎样推进、什么条件下等待、哪些结果需要重验，以及失败后从哪里恢复的运行结构。

08.1 Graph 的基本能力

能力	平台行为	认证案例
节点	定义输入、动作、输出和验收	T01–T06
依赖	只有前置结果满足时节点才 ready	T04 依赖 T03
条件分支	根据 Check 结果进入通过、修复或人工路径	A4 通过或失败
循环	在次数、时间和成本预算内重试或重验	修复后重跑 A4
人工节点	等待审批、补事实或接管	允许测试环境修改
影响关系	判断哪些验收和节点需要重新执行	T04 影响 A2、A3、A4
子图	把常用流程封装成可复用模块	认证回归子图

08.2 认证 Graph 示例

图 6 · 认证交付的可恢复 Graph

flowchart TD T01["T01 读取项目与规则"] --> T02["T02 盘点认证缺口"] --> T03["T03 实现认证接口"] --> T04["T04 接入页面与会话"] --> T05["T05 运行 A1–A5"] T05 --> D{"验收通过？"} D -- "是" --> T06["T06 生成交付说明"] D -- "否" --> R["记录失败证据"] --> F["修复或请求人工决策"] --> T05 T03 --> P["保存检查点"] P --> T04

08.3 Graph Builder 的用户体验与实现

Agent 构建者配置节点、输入输出、工具、依赖、重试预算和人工出口；任务用户主要查看当前节点、等待原因和下一步，不必编辑复杂 Graph。后台需要保存 Graph Schema、版本和节点状态，运行时将每次状态变化写入 Event，并让 Checkpoint 指向可恢复的节点输入。

本章产物：Graph Builder、节点 Schema、依赖和影响模型、审批节点、重试循环、子图和 Graph Version。

09 · 工具与权限：Agent 如何真正做事

本章要回答：平台如何把 Agent 的动作建议变成经过范围、参数、权限和风险检查的真实动作。

模型只能提出 Tool Proposal，不能直接访问文件、Shell、HTTP、浏览器、数据库或外部 API。Tool Gateway 是模型与真实世界之间的闸门：它检查请求，执行允许的动作，保存结果，并在不确定时停止扩大副作用。

09.1 Tool Center 管理什么

工具类型	认证案例	关键配置
文件工具	读取和修改认证代码	路径、读写、差异、回滚
Shell / Test	运行单测和回归	命令白名单、超时、资源预算
HTTP	登录、退出、/me 探针	目标地址、凭据引用、请求次数
Browser	页面登录和退出检查	测试环境、脱敏、只读默认
Git	读取分支和差异	仓库、分支、提交和合并权限
Production	第一版不提供	另建发布系统和人工审批

每个工具都应有稳定的 Schema：输入参数、输出结构、错误类型、幂等性、可能副作用和所需权限。这样 Agent 可以发现工具，平台也可以在执行前做静态检查，而不依赖一段自然语言描述。

09.2 Tool Gateway 如何判断一次调用

图 7 · Tool Proposal 到真实动作

flowchart LR A["Agent Tool Proposal"] --> B["校验参数与目标"] --> C["匹配 Project / Environment Policy"] --> D{"需要审批？"} D -- "是" --> E["等待 Decision"] --> F["执行或拒绝"] D -- "否" --> F F --> G["返回结果、风险和证据"]

Tool Policy
谁：用户、Agent、Reviewer
对什么：项目、目录、数据和服务
在哪里：Workspace、Branch、Environment
做多久：Task、Run 和授权时段
做多少：次数、CPU、时间和输出预算
风险：读、写、外发、生产和不可逆动作

用户需要看到 Agent 将执行什么、为什么执行、访问什么资源、是否需要审批和结果状态。结果不明时，平台保存 unknown，先查询或人工确认，不能把可能已经产生副作用的动作无条件重试。

本章产物：Tool Center、Tool Schema、Tool Gateway、Policy、风险分级、预算、幂等、审批和审计。

10 · 运行中心：平台如何管理 Agent 执行

本章要回答：平台如何把一次 Agent 执行变成可观察、可暂停、可恢复、可审计的 Run。

运行中心是通用平台区别于普通聊天产品的关键。它不只展示消息，而是管理一个有生命周期的 Run：绑定配置快照，推进 Graph，记录工具和用户事件，保存检查点，并在异常时告诉人下一步怎样处理。

10.1 Runtime Center 的核心对象

对象	作用	认证案例
Run	一次具体执行，绑定 Agent、Graph、Contract、代码和环境版本	R1、R2、R3
Process	实际运行的进程、队列或执行器	本地服务与测试进程
Event	状态、工具、检查和用户操作事件	Tool Call、A4 失败
Checkpoint	中断后恢复所需的状态和引用	写入代码后的恢复点
Retry	有边界的重新执行策略	修复后重验
Decision	审批、范围确认和人工判断	允许测试工具继续

10.2 用户如何处理运行状态

1. 查看：打开 Run，看到当前节点、最近事件、成本、权限和待办。
2. 暂停：平台停止继续取新动作，保存 Checkpoint 和原因。
3. 恢复：重新核对工作区、代码差异、环境健康和授权是否仍有效。
4. 重试：只重跑有明确策略的节点，不覆盖原 Run 的证据。
5. 取消：终止后续动作，保存已产生的副作用和未完成节点。
6. 接管：将待处理问题和上下文交给 Reviewer 或任务用户。

10.3 运行可靠性规则

问题	平台规则
重复创建	使用幂等键、唯一约束和副作用记录
事件断线	事件序号、游标补读和重放
旧 Run 迟到	版本和状态条件更新，不能覆盖新 Run
中断恢复	先核对 Checkpoint、工作区、权限和副作用
成本失控	模型、工具、时间、并发和输出预算
结果不明	进入 unknown，要求查询或人工决定

本章产物：Runtime Center、Run 状态机、Event Stream、Checkpoint、Pause / Resume / Cancel、Retry 和人工接管。

11 · 验证、证据与交付：平台如何判断完成

本章要回答：平台如何把观察转成检查、证据、验收和交付，避免把工具成功误认为业务完成。

“命令返回 0”“接口返回 200”都只是 Observation，不等于业务目标已经达成。平台的结果层需要建立一条可追溯的证据链：

Observation → Check → Evidence → Acceptance → Artifact → Delivery

11.1 认证案例的 A4 验收

退出接口返回 200 只说明请求被处理。平台必须保存退出前签发的原凭据，用同一凭据再次访问 /me，确认返回 401，才能证明 A4 通过。证据还要关联 Agent Version、Contract、代码版本、环境和产生时间，方便另一位用户复查。

图 8 · 从观察到交付的证据链

flowchart LR O["工具观察 退出返回 200"] --> C["验证检查 原凭据访问 /me"] --> E{"返回 401？"} E -- "是" --> P["Evidence 通过"] --> A["Acceptance A4"] E -- "否" --> F["Evidence 失败"] --> R["修复并重新运行"] --> C A --> D["Delivery 交付"]

11.2 Verification Center 的用户视图

页面内容	用户需要知道什么
验收状态	通过、失败、待复核、阻塞或证据过期
证据来源	哪次 Run、哪个工具、哪个代码和环境
检查方法	执行了什么输入、规则和比较
影响范围	哪些验收和节点需要重新运行
交付物	差异、测试、页面、说明和限制
未决事项	谁来处理、何时处理、阻塞什么

11.3 完成门槛

1. 当前 Contract 的目标、范围和非目标满足。
2. 所有必需 Acceptance 通过，失败项有明确处理结论。
3. Evidence 绑定当前 Agent、代码、环境和来源版本。
4. 没有未处理的高风险、权限和阻塞事项。
5. Delivery 可以被另一位授权用户复查并重新执行关键检查。

本章产物：Verifier、Check、Evidence、Acceptance、Artifact、Delivery、验收模板和交付报告。

12 · 平台管理与复用：如何把一次任务变成平台资产

本章要回答：平台如何判断哪些经验值得沉淀，并让下一次任务在边界清楚的前提下复用。

一次 Run 完成后，平台不能把所有临时内容都打包成模板。真正可复用的是经过验证的对象和关系；项目路径、临时凭据、一次性假设和未确认的模型总结，应继续留在原任务中。

12.1 可以沉淀哪些资产

资产	认证案例沉淀	复用时需要重新确认
Agent Template	认证交付 Agent	模型版本、职责、适用项目
Task Template	认证任务创建表单	目标、范围、项目和时限
Graph Template	T01–T06 与失败出口	节点输入、工具和重试预算
Tool Set	代码、测试、HTTP、浏览器	环境、路径、凭据和 Policy
Acceptance Template	A1–A5	领域检查器和通过门槛
Context Template	Session、路由、/me、测试环境	项目来源、版本和权限
Evaluation Set	A4 旧凭据失效回归	样例输入、预期输出和评分规则
Delivery Template	差异、测试、运行说明	交付对象、收件人和限制

12.2 Asset Center 的管理流程

图 9 · 从一次 Run 到可复用模板

flowchart LR R["完成 Run"] --> S["选择可沉淀对象"] --> C["去除项目敏感信息"] --> E["样例与边界评测"] --> P["发布版本"] --> U["授权复用"] --> M["收集指标与反馈"] --> S

管理中心要提供资产版本、发布、权限、适用范围、依赖关系、运行指标和回滚。复制 Agent 模板后应形成新版本；Graph、Tool、Policy 或 Acceptance 变化时，要显示影响，不能让历史 Run 静默引用未来配置。

12.3 从认证复用到相似项目

换一个权限或资料导出任务时，可以复用 Workspace、Project 接入、Task 生命周期、Runtime Center、Evidence 和 Delivery 页面，只替换 Agent 职责、领域 Graph、工具参数和验收模板。通用性体现在机制和边界可以复用，而不是把认证项目的路径和提示词原样复制。

本章产物：资产中心、模板、版本、发布、评测集、依赖关系、使用范围、指标、回滚和复用策略。

13 · 平台实现与验收：如何证明它是通用平台

本章要回答：平台如何从页面、API、领域对象、编排器、工具网关和事件流落地，并通过复用验收证明它不是案例 Demo。

最后验收的不是一套漂亮页面，而是一条能够被不同用户重复走通的产品链。认证项目是第一条验证链；平台是否通用，要看换用户、换项目、换 Agent 和换相似任务后，核心对象、状态和证据契约是否仍然成立。

13.1 最小实现架构

实现层	关键模块	第一版验收
前端	Workspace、Project、Agent、Task、Runtime、Evidence、Delivery	用户能完成完整使用路径
API	任务、运行、事件、工具、证据和资产接口	对象和状态可查询、可更新
领域层	Contract、Plan、Run、Check、Evidence、Asset	关系、版本和权限正确保存
执行层	Orchestrator、Context Builder、Tool Gateway、Verifier	T04 纵向切片跑通
基础设施	数据库、队列、对象存储、事件流和审计	中断、重放和恢复可验证

13.2 一条纵向切片怎样跑通

第一版不必同时实现所有行业能力，应先选择认证任务中的 T04→A4→Delivery 作为纵向切片：页面创建 Task，API 生成 Contract，领域层保存版本，Orchestrator 取上下文并调用 Tool Gateway，Verifier 产生 Evidence，Runtime Center 推送状态，Delivery 页面展示结果。切片跑通后，再扩展其他节点和模板。

图 10 · 从页面到执行器的最小闭环

flowchart LR UI["Task / Runtime / Evidence 页面"] --> API["API 与权限校验"] --> D["领域对象与数据库"] --> O["Orchestrator"] O --> C["Context Builder"] --> T["Tool Gateway"] --> V["Verifier"] --> E["Event / Evidence"] --> UI

13.3 四层平台验收

验收层	验证问题	通过标准
功能验收	平台能否完成认证项目？	A1–A5、失败修复、中断恢复通过
用户验收	用户能否独立使用平台？	能创建、运行、处理等待、接收交付
稳定性验收	异常时平台是否可靠？	重复请求、断线、超时、unknown 可处理
复用验收	换人、换项目、换 Agent 后是否仍可用？	核心模块和资产边界不需要重做

13.4 认证项目如何证明平台通用

1. 换用户：不提供阿明聊天记录，另一位授权用户仍能创建和完成任务。
2. 换运行：R1 失败、R2 修复、R3 交付之间状态和证据不互相覆盖。
3. 换项目：替换仓库、分支和环境后，Project 和 Context 能重新建立。
4. 换 Agent：替换模型或 Prompt 版本后，Task、Graph、Tool 和 Evidence 契约仍然稳定。
5. 换相似任务：权限或资料导出任务可以复用平台生命周期和运行中心。

13.5 平台放行条件

Platform Acceptance Report
功能：认证交付 A1–A5
用户：创建、运行、等待、接管、接收
稳定性：失败、中断、重复、超时、unknown
复用：换用户、项目、Agent、相似任务
资产：Agent、Task、Graph、Tool、Policy、验收模板
结论：ready / needs_rework / blocked

如果平台只能让阿明完成认证项目，它是案例工具；如果平台能够让不同用户通过配置完成认证、权限、资料导出等相似任务，它才具备通用交付能力。下一步才是把这些能力绑定到岗位、职责、知识和指标，进入数字员工平台。

本章产物：平台模块架构、API 与领域对象、纵向实现路线、四层验收、复用验收和平台放行报告。

思考：通用 Agent 平台的完成标准，不是模型变得更聪明，而是用户能在明确边界内完成任务，系统能留下状态和证据，并让下一次交付复用已经验证过的能力。