Agent 注册表 + AgentCore 计费拆解 + W15 周总结

日期: 2026-09-27 阶段: Phase 4 - 自建 Agent 平台×求职冲刺 标签: #agent-registry #versioning #agentcore-pricing #week-summary

核心问题

W15 三天（Day 103-105）把授权从「硬编码 if」做成了「声明式策略引擎 + 事中执行器」。但还差最后一块拼图：这些策略集、模型配置、工具绑定，挂在哪个对象上、怎么版本化、怎么不停机更新？ 一个「自建 Agent 平台」（P4 的命题）的核心数据结构，就是 Agent 注册表——它是「这个平台上跑着哪些 Agent、每个 Agent 是什么配置」的单一事实源。

今天回答三件事：

1. Agent 注册表该存什么、怎么版本化、怎么热更新？ 一个 Agent = 定义（身份）+ 版本（不可变快照）+ 绑定（模型配置 / 工具集 / 策略集）。改一条策略要不要重启 Agent？怎么做到「策略热更新、Agent 不停机」？
2. AgentCore ~12 计费组件到底怎么算？ P4 要做「平台」就绕不开成本模型。AgentCore 是纯消耗计费（无固定月费）——拆清它的 12+ 个独立计费项，才能回答「自托管 vs 托管」的选型，也才能回答面试官的「你这套架构月成本怎么估」。
3. W15 收了什么、SOTA 重审。

本篇含 W15 周总结。Agent 注册表是 Day 103/104 策略引擎的挂载对象——策略不是全局的，是绑定到具体 Agent 版本的。

关键内容

A. Agent 注册表的数据模型：定义 / 版本 / 绑定

Agent 注册表（agent registry）的工业定义（TrueFoundry, 2026）：「a centralized catalog of autonomous agents and their capabilities used for discovery, governance, and reuse」。MLflow 3.0（2026）把它扩到 GenAI——「connecting model versions to code snapshots, prompt configurations, and evaluation results... version code, data, prompts, and configs together so any deployed model can be reproduced or rolled back」。提炼出三层结构：

AgentDefinition (稳定身份，不变)
  ├─ id, name, ownerTeam, description
  └─ versions: AgentVersion[]        ← 一个定义，多个不可变版本

AgentVersion (不可变快照，版本化的单位)
  ├─ versionId (内容寻址：configHash)
  ├─ modelConfig:  { model, temperature, maxTokens, systemPromptHash }
  ├─ toolBindings: string[]          ← 引用 toolRegistry 的工具名（Day 103 action 集）
  ├─ policySetId:  string            ← 引用一组 Day 103 策略（关键绑定！）
  ├─ budgetConfig: BudgetConfig       ← Day 81/orchestrator budget 上限
  ├─ evalBaseline: { recall, fpr, judgeKappa }  ← Day 17/19 评测基线快照
  └─ createdAt(seq), status: draft|active|deprecated

AgentBinding (运行时活跃指针)
  └─ agentId → activeVersionId        ← 「现在线上跑哪个版本」，可原子切换

三条设计原则：

• 版本不可变（immutable versions）：AgentVersion 一旦发布，内容永不改——改任何配置 = 发新版本。versionId 用配置内容哈希（content-addressed），保证「同配置 → 同 versionId → 可复现」。这是 MLflow「reproduced or rolled back」的前提：回滚 = 把 AgentBinding 的指针指回旧 versionId，旧版本数据还在。
• 绑定是间接引用：toolBindings/policySetId 存的是引用（工具名 / 策略集 id），不是内联拷贝。这样一个工具/策略集能被多个 Agent 版本复用，且改工具实现不影响版本快照（版本快照的是「绑定了哪些」，不是工具代码本身）。
• 运行时指针与版本分离：AgentBinding.activeVersionId 是唯一的可变量——「线上跑哪版」。发布新版 = 创建 AgentVersion（不影响线上）→ 切 AgentBinding 指针（瞬时生效）。这就是热更新与回滚的机制。

B. 策略热更新：改一条策略，Agent 怎么不停机就生效？

这是注册表最微妙的地方，也是 Day 103/104 策略引擎与注册表的接缝。问题：合规官改了一条 AML 策略（如收紧跨境阈值），怎么让线上 Agent 立刻按新策略执行，又不丢「当时凭哪版策略判」的审计可追溯性？

两种做法的取舍：

本项目选后者——策略集是一等公民，独立版本化：

PolicySet (独立版本化)
  ├─ id, versions: PolicySetVersion[]
  └─ PolicySetVersion { versionId(=policiesHash), policies: Policy[], effectiveSeq }

AgentVersion.policySetRef = { policySetId, pinnedVersion? }
  ├─ pinnedVersion 有值 → 锁定该策略集版本（审计/合规冻结期用）
  └─ pinnedVersion 为空 → 跟随 PolicySet 的 active 版本（热更新生效）

热更新流程：合规官改策略 → 系统创建 PolicySetVersion（新 versionId = 新策略集内容哈希）→ 切 PolicySet 的 active 指针 → 未 pin 的 Agent 下一次 enforcePolicy（Day 104）即读到新版，无需重启。审计条目（Day 104 PolicyDecisionRecord）记录 policySetVersion + matchedPolicyId——保证「这次判定用的是哪版策略的哪条规则」永久可追。

反直觉洞察①（Agent「热更新」的安全前提是「版本不可变 + 指针原子切换」，而非「就地改配置」）：直觉上「热更新」= 找到线上 Agent，把它的策略字段改掉。这在合规系统里是埋雷的——就地改意味着：(1) 改的瞬间，正在执行的调用读到的是改前还是改后？竞态；(2) 出了问题想回滚，改前的配置已被覆盖，无从恢复；(3) 审计追不到「出问题那一刻用的是哪版配置」。正确范式是不可变版本 + 原子指针切换（借数据库 MVCC 与 Git 的思路）：永不就地改，只创建新版本、再原子地切一个指针。这样：进行中的调用读旧版本快照（一致），新调用读新版本（生效），回滚 = 指针指回（旧版本数据还在），审计 = 记录当时指针指向的 versionId（可复现）。「热」体现在指针切换是瞬时无停机的，而非「就地热改数据」——后者是把可变性引入了合规审计链，恰恰是 Day 75/104 要避免的。

C. AgentCore 计费拆解：纯消耗、12+ 组件、5 种计费模式

P4 做「平台」必须懂成本。AgentCore 是纯消耗计费——无前期/月固定费，「pay only for what you use」（AWS pricing, 2026）。但「纯消耗」的代价是计费维度极其碎：12+ 个独立计费组件，落 5 种计费模式。完整拆解（2026-06 口径，执行当周须重新确认）：

5 种计费模式：① 按会话活跃消耗（Runtime/Browser）② 按请求（Gateway/Policy/Identity/Memory 检索）③ 按记录·月（索引/长期记忆/注册表）④ 透传（CloudWatch/VPC/S3）⑤ 免费/预览（部分新功能）。外加一笔最大的隐藏成本：基础模型 token 费另算（不在这 12 项里，走 Bedrock 模型计价）。

反直觉洞察②（AgentCore 的「纯消耗、按需付费」对低频高 stakes 的 AML 场景反而可能比自托管贵，且最危险的成本是「无上限的可观测性」）：「pay only for what you use」听起来永远划算——但有两个陷阱。其一：Runtime Memory 按会话峰值计费且包含 idle 时间（CloudBurn 2026 明确「per-session peak including idle」），一个长会话的 AML 调查 Agent 即使在等人工复核（Day 104 escalate pending），内存仍在计费——高 stakes 场景的 HITL 等待期天然长，这笔 idle 成本被低估。其二、也是最危险的：Observability 是 CloudWatch 透传、ingestion 无上限（CloudBurn 列为「unbounded CloudWatch ingestion」隐藏成本）——AML 合规要求全链路 OTel 留痕（Day 22-24），trace 量大，这笔费用会悄悄超过 Runtime 本身。教训：选「纯消耗」平台时，真正要建模的不是标价高的 Runtime，而是按量透传且无上限的可观测性 + idle 内存——这恰好是合规重型场景（长 HITL + 全留痕）成本结构的反常之处。对低频（每天几十案）但每案重型的 AML，自托管（vLLM/NIM on K8s，Day 53 SOTA 已记为事实标准）+ 进程内确定性策略引擎（本项目 Day 103-104，Policy 计费 = $0）可能总成本更低且数据不出域——这正是本项目「自建轻量平台」相对全托管 AgentCore 的差异化论点。

D. W15 周总结（Day 103-105）

W15 把 P2 Day 53 风控网关、P3 Day 81 渐进式授权，抽象成了一套可声明、可分析、可版本化、可热更新、可审计的策略治理子系统——这是「自建 Agent 平台」相对「调 AgentCore API」的可展示纵深：不是会用别人的平台，是理解平台底层每个决策（为何 Cedar 四元组、为何协议外评估、为何不可变版本、纯消耗计费的成本陷阱在哪），并在自己的 AML Copilot 里复刻其确定性内核。

设计要点/决策表

对本项目的落地

• 新建 src/agent/registry/agentRegistry.ts：导出 AgentDefinition/AgentVersion/AgentBinding 类型（A 节三层）、PolicySet/PolicySetVersion（B 节独立版本化）、registerVersion(def, config): AgentVersion（内容哈希算 versionId，复用 Day 75 fnv1a）、activate(agentId, versionId)（原子切 AgentBinding 指针）、rollback(agentId)（指针回退）、resolvePolicies(agentVersion): Policy[]（按 policySetRef.pinnedVersion 取锁定版或 active 版，喂给 Day 104 enforcePolicy）。纯函数+内存 store，确定性可测。
• 接 Day 103/104 策略引擎：Day 104 的 enforcePolicy 不再直接读全局 AML_POLICIES，而是 resolvePolicies(currentAgentVersion) 取该 Agent 绑定的策略集——策略从「全局单例」升级为「Agent 版本绑定」，支持不同 Agent（调查 Copilot / SAR 起草）不同策略集。审计条目（Day 104 PolicyDecisionRecord）补 agentVersionId + policySetVersion 字段。
• 接 Day 81/budget 与 Day 17 评测：AgentVersion.budgetConfig 引 src/agent/orchestrator/budget.ts 的 BudgetConfig；evalBaseline 快照 Day 19 的 recall/fpr 与 Day 17 的 judge κ——发布新版本前断言 evalBaseline 不回退（呼应 Day 19 阻断式 CI gate：评测不达标的 Agent 版本禁止 activate）。
• AgentCore 计费拆解落文档：把 C 节 12 项计费表 + 5 模式 + 自托管对比，写进 docs/aipa/ 的 P4 长文（Day 105 是素材日），作为面试「你这套架构月成本怎么估」「为何不直接用 AgentCore」的论据——本项目进程内确定性策略引擎使 Policy 计费=$0、数据不出域，是相对全托管的差异化论点。
• 诚实标注：agentRegistry.ts 头注写明——v1 是 Agent 版本化/热更新/回滚的内存确定性实现（内容寻址 versionId + 指针切换语义），非生产注册表（无持久化存储、无并发控制、无分布式一致性）；AgentCore Agent Registry 仍 Preview（2026-06），计费/能力执行当周须重新确认；真实多 Agent 编排、跨进程注册、持久化为接后端后续。

参考资料

1. CloudBurn — Amazon Bedrock AgentCore Pricing: 12 Components Breakdown：完整 12+ 计费组件单价（Runtime $0.0895/vCPU·h + $0.00945/GB·h、Gateway $0.005/1K calls、Policy $0.000025/req、Memory 短期/长期/检索、Identity、Evaluations、Observability CloudWatch 透传）；5 计费模式；「per-session peak including idle」「unbounded CloudWatch ingestion」「CPU not billed during I/O wait」隐藏成本；Agent Registry Preview freemium (2026)
2. AWS — Amazon Bedrock AgentCore Pricing：纯消耗、按需付费、无前期费用 (2026)
3. TrueFoundry — What is AI Agent Registry — A Complete Guide：注册表=自治 Agent 及能力的中心化目录，用于发现/治理/复用 (2026)
4. MLflow — ML Model Registry / MLflow 3.0 for GenAI：连接模型版本↔代码快照↔prompt 配置↔评估结果；版本化 code/data/prompts/configs 以可复现/回滚 (2026)
5. 本仓库 src/agent/policy/policyEngine.ts（Day 103 策略集，被注册表绑定）、src/agent/policy/enforcer.ts（Day 104 enforcePolicy，改读 resolvePolicies）、src/agent/orchestrator/budget.ts（BudgetConfig 入版本）、src/aml/auditTrail.ts（Day 75 fnv1a 算 versionId）、src/aml/evalBaseline.ts（Day 19 基线入版本快照）(2026-06)

SOTA 检查 (2026-06-11)

• Agent 注册表 + 版本化 + 不可变快照是 2026-06 AgentOps 的成型实践：MLflow 3.0（GenAI 版本化）、TrueFoundry（agent 注册表治理）、AgentOps 学科（waxell/blockchain-council 2026）三方一致——agent 要像模型一样版本化、可复现、可回滚、可治理。AgentCore 也已上 Agent Registry（2026-06 Preview），印证方向。本项目内存版复刻其内核语义（内容寻址版本 + 指针切换）。
• AgentCore 纯消耗计费的「碎」是 2026 平台共性、非 AWS 独有：Google Agent Engine（$0.0864/vCPU·h 运行时 + $0.25/千事件，CLAUDE.md 已记）、AgentCore（12+ 组件）都走细粒度按量——好处是低频省钱、坏处是成本难估且隐藏项多（idle 内存、无上限可观测性）。本项目「自托管 + 进程内确定性策略（Policy=$0）」对 AML 低频高 stakes 是合理差异化，但须诚实：自托管的运维成本（K8s/vLLM 维护）转嫁到了人力，非真的「免费」。
• 「不可变版本 + 原子指针切换」是借数据库/Git 的成熟范式：与 DSDB 计划学的 MVCC（多版本并发，读旧写新不阻塞）、内容寻址（Git object）同源——把分布式系统的版本化思想迁到 agent 配置治理，是本项目跨计划的可展示交叉（DSDB×AIPA）。2026-06 未见把此范式标准化的 agent 平台规范，是设计空白点。
• 成本透明度正成选型显性维度：第三方涌现 AgentCore 成本计算器（CloudBurn/Tech42/clawaws 2026），说明「12 组件纯消耗」复杂到需要专门工具估算——这反向印证反洞察②「真成本难估、隐藏项多」是普遍痛点，也是本项目「能讲清平台成本结构」的面试加分点（AISA 作品集铁律=产品结果+eval 数字+单位成本，CLAUDE.md 已记）。
• 过时认知警示：「Agent 配置就地热改」是危险过时做法（竞态/丢回滚/审计断链，反洞察①）；「纯消耗一定比固定费便宜」对长 HITL + 全留痕的合规重型场景不成立（idle 内存 + 无上限可观测性，反洞察②）。两者都是 P4 平台尺度才暴露的坑。
• 待跟踪：(a) AgentCore Agent Registry 何时 GA、计费转正后单价（当前 Preview freemium）；(b) 本项目 evalBaseline 入版本快照后，「禁止评测回退的版本 activate」与 Day 19 CI gate 如何统一；(c) 长会话 idle 内存成本在接真实 AgentCore 时实测，验证反洞察②对 AML HITL 等待期的量级判断。