长文#6 初稿 — build-vs-buy 解剖：我自建的每个零件，托管平台收你哪一层的钱

日期: 2026-10-03 阶段: Phase 4 - 自建 Agent 平台×求职冲刺 标签: #longform6 #component-mapping #defense-in-depth

核心问题

Day 110 把 v1 合龙了，也把 TCO 公式立了。今天起草长文#6——作品③的叙事文档。这篇长文要回答一个面试官真正在意的问题：

「你自建了一个 agent 平台。那托管平台（AgentCore / Foundry / Gemini Enterprise）到底提供了什么？你自建的那些零件，分别对应它们收费的哪一层？哪些层你值得自建，哪些层你绝不该自建？」

这篇长文的杀手价值不是「我会自建」，而是**「我自建过，所以我能逐层拆解托管平台在卖什么」**。techinterview（2026）说得直白：「2026 资深候选人的标准面试物料是『我用 AI 建了 X』，HM 评估的是 design taste、evaluation rigor、shipping ability」——而「逐层对应自建零件↔托管组件」正是 design taste 的硬证据。今天产出长文上半骨架（A/B 节）+ 核心组件对应表（C 节）。

关键内容

A. 自建过程与组件对应：每个零件都是托管平台的一层

把 P2 五个教学装置 + Day 110 新增的 policyGate，逐一对到三家托管平台正在收费的组件。这不是类比，是一一对应的同构——因为托管平台卖的本就是「把这些零件做成托管服务」。

自家会话运行时 ↔ Runtime。checkpointMachine.ts 复刻的是 LangGraph 式 durable execution：逐步推进 + 每步落 checkpoint + 崩溃续跑 + 幂等重放。托管侧对应 AgentCore Runtime——microVM-per-session 隔离（借 Lambda 但调成 8h 长会话），Foundry 对应 per-session hypervisor 隔离 + 每 agent 一个 Entra agent identity，Google 对应 Agent Engine 托管运行时。自建零件解决的核心问题（崩溃不丢状态）正是 Runtime 收费要解决的问题——只是托管侧把 checkpoint 写进 durable store（Postgres/DynamoDB）而非内存。

自家网关 ↔ Gateway。semanticCache.ts（双层语义缓存）+ toolRegistry.ts（MCP tools/list + tools/call + schema 校验）合起来对应 AgentCore Gateway——把企业 API/Lambda/OpenAPI 零代码转成 MCP 工具，并提供 x_amz_bedrock_agentcore_search 语义搜索解决「工具过载」（AWS 2025-08：上百工具时全暴露会导致 hallucination，必须语义检索按需暴露）。我的 toolRegistry 复刻了「工具暴露契约层」，semanticCache 复刻了「网关计量+缓存」——但 Gateway 还多了我没做的：协议转换（REST→MCP）+ 入站/出站授权。

自家策略门 ↔ Policy。Day 110 新增的 policyGate（「draftSar 前必须先 fetchKyc」式规则）对应 AgentCore Policy——2026-12 preview，「自然语言→Cedar 策略，集成 Gateway 实时拦截每一次工具调用」。这是我自建零件里最该对标托管的一层（见 C 节反直觉）。

自家计量 ↔ Observability + 计费。budget.ts（addCost + costCapUsd 硬闸）+ CostMeter 对应 CloudWatch Observability + 按组件计费。我的计量是「省钱+熔断」，托管的计量是「计费+监控」——同一份遥测，两种用途。

自家记忆 ↔ Memory。memory/（contextBuilder/summarizer/pinnedFactsStore）对应 AgentCore Memory（短期事件 + 长期记录，managed 自动抽取 / self-managed 全控制两种策略）。

B. 上半骨架：从"五个 demo"到"一篇能讲清取舍的长文"

长文#6 上半（约 2/3 篇幅）的骨架：

长文#6《build-vs-buy 解剖：自建一个 agent 平台，看清托管平台卖什么》

├─ 0. 引子：为什么自建？（不是为省钱，是为"看清每一层"）
│     钩子：托管平台报价单有 ~12 个组件，但你不自建一遍，
│            永远不知道每个组件在解决什么问题、值不值那个钱。
│
├─ 1. 五个零件 + 一条链（合龙）          ← Day 110 A 节六段冒烟
│     注册→策略→durable→计量→面板，一条 AML 调查闭环
│
├─ 2. 逐层对应：我的零件 ↔ 托管组件      ← 本日 A 节 + C 节对应表
│     · 会话运行时 ↔ Runtime
│     · 网关+工具表 ↔ Gateway
│     · 策略门 ↔ Policy（defense-in-depth）
│     · 计量 ↔ Observability+计费
│     · 记忆 ↔ Memory
│
├─ 3. 防御纵深三层：Identity / Gateway / Policy   ← 本日 C 节
│     这是自建最难补、最该买的一层
│
├─ 4. TCO：买 vs 自建同构公式            ← Day 110 B 节（下半，Day 112 收）
│     隐性成本：token 另算 / 观测无上限 / 运维人力 25-30%
│
└─ 5. 决策树：什么客户该 build / 该 buy   ← Day 112 A 节收尾
      含 HIPAA/数据驻留例外

为什么上半先讲「逐层对应」而非先讲 TCO：因为 TCO 数字（$0.0895/vCPU·h、运维 25-30%）只有在读者先理解每个组件在干什么之后才有意义。先建立「Gateway 是协议转换+授权层」的认知，「Gateway $0.005/千次调用」这个价才能被判断贵不贵。叙事顺序 = 认知依赖顺序——这是长文与堆参数表的区别。

反直觉洞察①（自建的价值在"看清"，不在"省钱"）：直觉是「自建为了省托管费」。但本项目作品③自建的真正回报，是逐层拆解托管平台的能力——一个没自建过的人看 AgentCore 报价单的 12 个组件，只觉得「好多收费项」；自建过的人能说「Gateway 在收『M×N 工具集成问题』的钱、Policy 在收『每次工具调用实时拦截』的钱、Identity 在收『token 保险库 + 凭证轮换』的钱，这三层我自建到 Policy 就够呛、Identity 我根本不该自建」。面试官买的是这种"逐层判断该买该建"的能力，不是"我省了多少钱"。 自建是为了获得判断力，不是为了获得节省。

C. 组件对应表：自建组件 × 托管对应 × 自建理由（核心交付物）

长文#6 的核心表——把「我建了什么、对应托管哪层、为什么我选择自建而非买」三栏钉死。这张表是整篇长文的脊椎：

防御纵深三层（Identity / Gateway / Policy）是这张表的重点。hidekazu-konishi（2026）把 AgentCore 安全总结为「defense-in-depth：Identity（认证层）+ Gateway（工具暴露层）+ Policy（授权层）」三服务组合。我的自建只覆盖了 Gateway（toolRegistry 的 schema 校验）和 Policy（policyGate 的规则拦截）的最小形，Identity 这层我刻意不自建——因为 token 保险库、OAuth 3LO/2LO、凭证轮换是安全敏感度最高、自建最容易出漏洞的一层。

反直觉洞察②（最该自建演示的 Policy 层，恰恰最不该在生产自建）：直觉是「能自建的层就自建省钱」。但 Policy（实时拦截每次工具调用的授权层）是演示价值最高、生产自建风险最高的一层。演示价值高——因为「draftSar 前必须先 fetchKyc」这种业务规则拦截，是 AML 场景最能体现「我懂 agent 安全」的点；生产风险高——因为授权层一旦有缺口（漏拦一次越权工具调用），后果是合规事故而非性能问题。AgentCore Policy 之所以做成「集成 Gateway 实时拦截每一次调用」+「自然语言→Cedar 形式化策略」，正是因为这层要的是形式化可验证 + 无遗漏拦截，远超一个 if-else policyGate 能保证的。所以作品③里 policyGate 是『我理解这层在干什么』的证据，而长文要明说『生产我会买 Policy，不会自建』——这种"自建到此为止"的边界感，才是架构判断力。

设计要点/决策表

对本项目的落地

• 新建 docs/aipa/longform6-build-vs-buy.md（初稿，本日落上半）：按 B 节骨架写 0-3 节（引子 + 合龙 + 逐层对应 + 防御纵深），C 节对应表作为第 2 节脊椎表。4-5 节（TCO + 决策树）留 Day 112 定稿补。头注标「初稿，下半 Day 112 补，定价 2026-06 口径」。
• 对应表直接复用 v1 物证：表中每个自建组件指向真实文件（checkpointMachine.ts/toolRegistry.ts/semanticCache.ts/policyGate.ts/budget.ts/CostMeter.tsx/memory/），不写虚构组件。这是长文「shipped system」可信度的根基——每行都能点开看代码。
• policyGate 头注呼应长文边界：在 src/agent/gateway/policyGate.ts 头注明确「本装置是 AgentCore Policy 的进程内最小复刻（if-else 规则），生产应买 Policy（Cedar 形式化 + 实时无遗漏拦截），不应自建——见长文#6 反直觉②」。让代码与叙事的「自建边界」一致。
• Identity 的"刻意不自建"写成显式 ADR：在长文第 3 节和 README 里明说「Identity（OAuth token 保险库）是刻意未自建的一层，理由：自建凭证轮换=安全负债」。显式说出"我没做什么、为什么不做"比堆"我做了什么"更显架构成熟度（呼应 AISA 面试「interviewers care about tradeoffs not output」）。
• 诚实标注：A/C 节所有托管组件描述（Runtime microVM 8h、Gateway 语义搜索、Policy 实时拦截、Identity token 保险库）均为 2026-06 口径的官方/第三方公开资料，Policy/Evaluations 仍 preview；自建装置全是教学复刻非生产实现（无网络/无真持久化/无真授权），长文须通篇标这条限定语，延续 P2 装置头注的诚实纪律。

参考资料

1. AWS — Introducing Amazon Bedrock AgentCore Gateway（官方博客，2025-08-15）：Gateway 把 OpenAPI/Smithy/Lambda 零代码转 MCP 工具；x_amz_bedrock_agentcore_search 语义搜索解工具过载；入站 OAuth（Cognito/Okta/Auth0，3LO/2LO）、出站 IAM/API key；凭证经 AgentCore Identity token 保险库存储缓存
2. hidekazu-konishi — Amazon Bedrock AgentCore Implementation Guide Part 2: Multi-Layer Security with Identity, Gateway, and Policy（2026）：defense-in-depth 三服务组合——Identity（认证层）/ Gateway（工具暴露层）/ Policy（授权层）
3. AWS — Amazon Bedrock AgentCore Overview（docs，2026 持续）：Runtime serverless 托管、Memory（managed/self-managed 两策略）、Policy 集成 Gateway 实时拦截每次工具调用、Browser/Code Interpreter
4. agentmarketcap — AWS Bedrock AgentCore vs Azure vs Google Vertex: Q2 2026 Managed Agent Runtime Comparison（2026-04-09）：AgentCore microVM-per-session 8h；Foundry per-session hypervisor + Entra agent identity；Google Agent Engine $0.0864/vCPU·h；模型 token 主导成本 10-100×，三家 compute 差异 <2-3%
5. techinterview — The AI Portfolio: What "Built With AI" Means in 2026 Interviews（2026）：「我用 AI 建了 X」是资深候选标准物料；HM 评 AI fluency / design taste / evaluation rigor / shipping ability；架构候选「interviewers care about tradeoffs not output」
6. 本仓物证：src/agent/durable/checkpointMachine.ts、src/agent/mcp/toolRegistry.ts、src/agent/gateway/semanticCache.ts、src/agent/gateway/policyGate.ts（Day 110 新增）、src/agent/orchestrator/budget.ts、src/agent/ui/CostMeter.tsx、src/agent/memory/（2026-06）

SOTA 检查 (2026-06-11)

注：本笔记日历日为 2026-10-03；事实核查与一手原文检索（AgentCore Gateway 博客、AgentCore docs、hidekazu-konishi、agentmarketcap）在 2026-06-11 完成。组件 GA/preview 状态为 2026-06 口径，定稿当周须重新确认（Policy/Evaluations preview→GA 可能改变能力与计价）。

• 「Identity/Gateway/Policy 防御纵深三层」是 2026-06 托管 agent 平台的安全主流架构：AgentCore docs、hidekazu-konishi 口径一致——认证/工具暴露/授权三层分离。本日对应表与此对齐，自建只覆盖后两层最小形、显式不碰 Identity。
• 「逐层对应自建↔托管」契合 2026 AISA 面试范式：techinterview/theinterviewguys（2026）——HM 评 design taste 与 tradeoff 判断而非 output 数量。「我建了什么 + 我刻意没建什么 + 为什么」是比纯 feature 清单更强的物料，本日长文骨架据此设计。
• 三家组件命名/边界仍在动：Google 2026-04 更名 Gemini Enterprise Agent Platform、AgentCore Policy/Evaluations 2026-12 preview——长文定稿当周须复核三家最新组件名与 GA 状态，避免引用过时品牌名（如「Vertex AI Agents」旧称）。
• 过时认知警示：(1) 不可把自建当「为省钱」——价值在「看清每层」（反直觉①）；(2) 不可把「能自建就自建」当原则——Policy/Identity 演示可建、生产该买（反直觉②）；(3) 自建装置全是教学复刻，长文须通篇标限定语，不得暗示生产级。
• 待跟踪（定稿当周）：复核 AgentCore Policy 是否已 GA + Cedar 策略语法；复核 Foundry Agent Framework 1.0（2026-04-03，SK+AutoGen 统一后继）与 Google ADK 的对应组件，把三家防御纵深并排进长文第 3 节；确认 Identity「不自建」的 ADR 措辞与最新安全最佳实践一致。