平台化开工 — Agent 平台五件套的组件边界设计

日期: 2026-09-21 阶段: Phase 4 - 自建 Agent 平台×求职冲刺 标签: #agent-platform #agentcore #component-boundaries

核心问题

P1-P3 已经把 AML Copilot 的一个 agent 从产品定义、评测底座、可观测、编排、记忆、网关、合规一路打穿。P4 要换一个视角：如果再来第二个、第三个 agent（KYC 复核、制裁名单筛查、交易监控），它们要共享哪些基础设施？ 这就是「agent 平台」的命题——不是再写一个 agent，而是把「跑 agent 所需的横切能力」抽成平台层。

今天回答三个问题：

1. 平台到底由哪几个组件构成？ 我立的是「五件套」：工具网关 / 策略引擎 / agent 注册表 / 会话运行时 / 计量。为什么是这五个、不是三个或八个？必须有一个权威参照来校验边界划得对不对——AWS Bedrock AgentCore（2025-10-13 GA）是目前最完整的企业级 agent 平台，逐一对照它的服务边界。
2. 哪些我自建、哪些我直接用托管？ 一个个人作品集项目不可能也不应该重造一遍 AgentCore。关键是讲清每个托管组件为什么存在——把边界讲透，比把代码写全更有价值。
3. AgentCore Policy / Evaluations 现在是什么状态？ 这两个组件 2025-12 还是 preview，写笔记前必须重新核实——否则引用就过时了。

关键内容

A. 五件套 ↔ AgentCore 服务的逐一映射

先把 AgentCore 的服务清单抓回来（WebFetch 官方 Overview 文档，2026），它现在是模块化、可独立或组合使用的一组服务，官方原话：「AgentCore services work together or independently with any open-source framework such as CrewAI, LangGraph, LlamaIndex, and Strands Agents」。我的五件套是从这张清单里按「AML Copilot 实际需要的横切能力」收敛出来的子集：

我的平台五件套                 AgentCore 对应服务            这一层解决的根本问题
─────────────────────────────────────────────────────────────────────────────
① 工具网关 ToolGateway   ──►  Gateway                   "怎么把内部 API/函数安全地暴露给 LLM 调用"
   （注册+鉴权+审计三合一）     +Identity（凭证保险库）      —— 工具发现 + 凭证最小权限 + 调用审计
② 策略引擎 PolicyEngine  ──►  Policy（Cedar，GA 2026-03）  "agent 能调哪个工具、什么条件下不能"
                                                          —— 在工具执行前确定性拦截，独立于 LLM 推理环
③ agent 注册表 Registry  ──►  Registry                  "组织里有哪些 agent/工具，谁批准上线"
                                                          —— 发现 + 治理 + 版本，多 agent 才需要
④ 会话运行时 SessionRT   ──►  Runtime（microVM 隔离）     "agent 跑在哪、会话怎么隔离、状态怎么续"
                                                          —— 隔离执行 + 长会话 + durable 续跑
⑤ 计量 Metering          ──►  Observability+消耗计费      "每个 agent/会话/工具调用花了多少"
                                                          —— 单位成本归因 + OTel 链路

注意几处边界的取舍：

• 工具网关把 AgentCore 的 Gateway + Identity 合成了一件。AgentCore 把「工具暴露」（Gateway）和「凭证保险库」（Identity，OAuth 令牌 vault）拆成两个服务，因为企业级要支持 Okta/Entra ID/Cognito 多 IdP、要跨 agent 共享身份。我的项目只有一类调用者（AML Copilot 自己），把鉴权折进网关一层即可——边界划在「调用者数量」上：单调用者合并，多 IdP 才拆。
• 策略引擎单列、不并进网关。这是 AgentCore 给的关键启发：Policy 是独立于 agent 推理环的确定性拦截层（官方原话「outside of the agent's reasoning loop」「intercept AgentCore Gateway tool calls before they run」）。它在 Gateway 之上，每次工具调用前用 Cedar 策略判定 allow/deny。我把它和网关分开，正因为「能不能调」（策略）和「怎么调」（网关）是两个关注点——前者是合规边界，后者是协议适配。
• 会话运行时我不真正自建 microVM。AgentCore Runtime 用 microVM 做真隔离、支持 8 小时长会话、A2A 协议。我的项目跑在前端（output:export 纯静态），不可能起 microVM——所以运行时这一件我只复刻语义形状（会话状态 + durable 续跑），用 P2 已建的 checkpointMachine 撑。

B. 自建范围与边界：为什么自建（且只自建一部分）

一个尖锐的反问：AgentCore 都 GA 了、12 个计费组件全套托管，我为什么还要自建一个「教学平台」？答案不是「省钱」（个人项目本就跑不起 AgentCore），而是边界的价值在「讲清每个托管组件为什么存在」。决策表：

反直觉洞察①（自建的价值不在「替代托管」，而在「逼自己讲清每个托管组件为什么必须存在」）：直觉是「平台都被 AWS 做完了，自建是重复造轮子」。但作为求职作品，AgentCore 是一个黑盒——面试官问「你为什么需要一个独立的策略引擎、不能把规则写进 agent prompt 里？」，只会用 AgentCore 的人答不上来，自建过薄壳的人能立刻答：「因为 prompt 里的规则是概率性的、可被越狱绕过，而策略引擎在工具执行前做确定性拦截，独立于 LLM 推理环——这正是 AgentCore Policy 用 Cedar + 自动推理（neuro-symbolic）而非用 LLM 判定的原因。」边界讲清 > 功能写全。 一个能解释「为什么 Gateway 和 Identity 要拆、Policy 为什么不能进推理环」的人，比一个会调 AgentCore API 的人更像架构师。

C. AgentCore Policy / Evaluations 的 GA 状态核实（★今日必查）

P4 计划立项时（按 2025-12 口径）Policy / Evaluations 都标 preview。但写笔记前 WebSearch + WebFetch AWS 官方博客（2026），状态已变，必须更新：

反直觉洞察②（平台组件的 GA 状态是「会过期的事实」，引用前必须当周重查）：直觉是「计划文档里写了 preview，照抄就行」。但 AgentCore 从 2025-10 GA 到 2026-06，半年里 Policy、Evaluations 双双转正、还新增了 Registry/Payments/Harness 三个服务——任何「某组件是 preview」的断言，三个月就可能失效。合规系统尤其不能用过期的平台能力清单做选型。本笔记所有 GA 状态标注为 2026-06 口径，执行当周需重新确认。

设计要点/决策表

对本项目的落地

• 新建 src/agent/platform/boundaries.ts：导出五件套组件的边界声明（PlatformComponent = { name, agentCoreEquiv, buildDecision: 'self'|'reuse'|'doc-only', boundary }），作为 P4 平台层的「地图」。它是纯数据 + 类型，不含逻辑——是给 day100-102 三天工具网关落地的目录索引。
• 目录结构开张：src/agent/platform/ 作为平台层根目录，与 P2 的 src/agent/gateway/（semanticCache）、src/agent/mcp/（toolRegistry）并列。day100-102 会把 mcp/toolRegistry.ts「升级」进 platform/gateway/，但不删旧文件——P2 装置保留为「进程内 MCP 协议形状」教学，平台层是其「多 agent 复用」的演进。
• 对照层文档：boundaries.ts 头注以表格形式内嵌「五件套 ↔ AgentCore 服务」映射（A 节），并标注每个 AgentCore 组件的 GA 日期（Policy 2026-03-03 / Evaluations 2026-03-31）与「执行当周重查」纪律——与 attributeMap.ts 头注核实 semconv 漂移同模式。
• 诚实标注：注册表（③）在 v1 只有边界声明、无实现；会话运行时（④）、计量（⑤）指向已存在的 durable/checkpointMachine.ts、Budget/CostMeter，不重建。平台层真正新写的代码集中在 day100-102 的工具网关三件。

参考资料

1. AWS — What is Amazon Bedrock AgentCore?（Overview 官方文档）：模块化服务清单（Runtime/Harness/Memory/Gateway/Identity/Code Interpreter/Browser/Observability/Payments/Evaluations/Policy/Registry）；「services work together or independently with any open-source framework」；Runtime「true session isolation」「multi-agent」；Policy「intercept every tool call before execution」「outside the agent's reasoning loop」 (2026)
2. AWS Blog — Amazon Bedrock AgentCore adds quality evaluations and policy controls for deploying trusted AI agents：Policy GA「March 3, 2026」、Evaluations GA「March 31, 2026」；Policy 用 Cedar + 自然语言 + 自动推理（neuro-symbolic）；Evaluations 内置评估器维度 + CloudWatch dashboard (2026)
3. AWS — Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows：Cedar + 神经符号反馈环（LLM 生成策略，Cedar Analysis 符号化校验）(2026-05)
4. AWSInsider — Amazon Bedrock AgentCore Now Generally Available：GA 2025-10；Runtime 8 小时执行窗口 + A2A；Gateway IAM + OAuth；全服务支持 VPC/PrivateLink/CloudFormation (2025-10)
5. CloudBurn — Amazon Bedrock AgentCore Pricing: 12 Components：Runtime $0.0895/vCPU-hour + $0.00945/GB-hour，per-second 计费，128MB 最小内存 (2026-04)
6. 本仓库 src/agent/mcp/toolRegistry.ts（P2 工具注册，将升级进平台层）、src/agent/gateway/semanticCache.ts（P2 网关）、src/agent/durable/checkpointMachine.ts（运行时 durable 语义）、src/aml/observability/attributeMap.ts（计量/OTel 映射） (2026-06)

SOTA 检查 (2026-06-11)

• AgentCore 是 2026-06 企业级 agent 平台的边界参照标杆：从 2025-10-13 GA 到 2026-06，已扩展到 11+ 模块化服务，且 Policy（2026-03-03 GA）、Evaluations（2026-03-31 GA）从 preview 转正——本笔记五件套映射据此核实，与立项时 2025-12 preview 口径不同，已更新。
• 三家云的平台边界正在收敛到同一组件清单：AgentCore（Runtime/Gateway/Identity/Memory/Observability/Policy/Eval/Registry）、Microsoft Foundry Agent Service（Responses API 运行时 + Evaluations GA 2026-03-16 + Entra Agent ID）、Google Gemini Enterprise Agent Platform（Agent Engine 运行时 + Memory Bank GA 2025-12 + A2A v1.2）——五件套的「网关/策略/注册表/运行时/计量」抽象在三家都成立，说明这是真实的平台边界，不是我臆造。
• 「策略引擎独立于推理环」是 2026 的明确共识：AgentCore Policy 用 Cedar + 自动推理而非 LLM 判定，正因为合规拦截要确定性、可证明、不可被越狱绕过——本笔记反直觉洞察①与此对齐。
• 过时认知警示：「Policy/Evaluations 是 AgentCore 的 preview 特性」已过时（2026-03 双双 GA）；「AgentCore 只有 7 个服务」过时（现 11+，新增 Registry/Payments/Harness）。任何「某组件 preview」断言，执行当周需用 WebSearch 重新确认。
• 待跟踪：AgentCore Registry GA 后是否公布跨云 agent 发现标准；Microsoft Agent Framework 1.0（2026-04-03 LTS）的图工作流是否影响我「会话运行时」边界；Open Group 截至 2026-06 仍无 TOGAF×agentic 标准，平台组件边界仍是各家自定义——这恰是作品集可切入的空白。