回路 / The Loop — 提出有价值的问题，比直接获取答案更重要。
这个专题收集和整理我与 Gemini、ChatGPT、Claude 等 AI 的对话记录。每一篇对应一次完整的提问与回答过程。通过留存这些层层追问，还原日常思考的真实轨迹。
概要
这是一场围绕 Anthropic Managed Agents 架构设计的深度对话。从”这个产品到底是给谁用的”出发，逐步推进到 Harness（调度循环）的底层运行机制、“脑手分离”带来的工程红利、小模型前置路由的工具剪枝方案，最终落到一个极具实战价值的工程冲突：动态替换工具集与 Prompt Caching 严格前缀匹配之间的对立。每一层追问都在拆解一个看似”已经理解”但实操中会踩坑的工程假设。
核心结论：Managed Agents 通过无状态 Harness + 持久化 Session 日志实现了工业级容错；小模型前置路由能显著提升工具选择准确率，但会破坏 Prompt Cache 的前缀命中——实际落地需要在”工具分桶”或”子会话派生”中找到平衡点。
Q: Anthropic Managed Agents 是什么？从企业管理者角度看，它解决什么问题？
Managed Agents 是 Anthropic 推出的企业级 AI Agent 托管运行平台。它将开发者从 Agent 基础设施的搭建中解放出来——运行循环、安全沙箱、错误恢复、状态管理——全部由云端服务承担，开发团队只需关注业务逻辑。
从企业管理者的视角，它解决三个核心痛点：
研发效能：传统模式下，上线一个稳定的 AI Agent 约 80% 的工程工作量消耗在”隐形基建”上——搭建代码执行沙箱、编写调度逻辑、处理断线重连。Managed Agents 把这些变成开箱即用的云端服务。
安全合规：生成式 AI 最致命的风险是数据泄露与越权操作。Managed Agents 通过沙箱隔离（AI 生成的代码在完全隔离的容器中运行）和凭证保险库（Credential Vault，API Token 托管在沙箱外部，AI 只能使用但无法读取真实密钥）实现了物理级安全边界。
成本控制：采用”脑手分离”架构，计算容器按需秒级拉起，不用时不占资源。会话日志独立持久化存储，容器崩溃可秒级重建并无缝接续上下文。据 Anthropic 工程博客披露，该架构使 p50 首字延迟（TTFT, Time to First Token）降低约 60%，p95 延迟降低超过 90%。
Q: Managed Agents 和 OpenAI 的 GPTs 有什么本质区别？
两者虽然都叫”智能体”，但面向的场景和技术架构有代际差异：
| 维度 | OpenAI GPTs | Anthropic Managed Agents |
|---|---|---|
| 定位 | 面向大众的 SaaS 级应用组件 | 面向开发者/企业的 PaaS 级托管基础设施 |
| 执行能力 | 局限于聊天对话、文档检索、简单 HTTP API 调用 | 能在云端沙箱中执行真实的 Bash 命令、Python 代码、读写文件 |
| 运行架构 | 强绑定在对话框内，同步状态机 | 脑手分离，AI 可在后台自主运行数小时 |
| 安全模型 | 数据调用与前端配置绑定 | 凭证保险库隔离，沙箱内代码无法接触真实密钥 |
| 分发方式 | GPT Store，绑定 ChatGPT 界面 | API 导向，企业自行路由到企业微信/Slack/自建系统 |
一个关键的设计哲学差异：GPTs 要求用户在 OpenAI 的界面中消费；Managed Agents 认为 Agent 的最终交互界面应由企业自行定义。 Anthropic 只做最难的云端算力和安全隔离，至于 Agent 出现在企业微信、Slack 还是自建系统里，由企业通过 API 自行路由。
Q: Harness 到底是什么？为什么它是 Agent 架构的核心？
Harness（调度循环）是 Agent 的”神经中枢”——那段负责让 AI “动起来”并持续循环的底层控制代码。
大语言模型本身是静态且被动的：你给它一个输入，它给你一个输出，对话就结束了。要让 LLM 变成能自主解决问题的 Agent，必须在模型外面套一层控制代码，在后台跑一个循环（通常称为 ReAct 循环）：
[用户输入] → [Harness 接收] → [询问 LLM: "下一步干嘛？"]
→ [解析 LLM 意图] → [触发工具/运行代码] → [捕获结果]
→ [把结果追加到上下文] → [再问 LLM: "然后呢？"]
→ (循环直到任务完成)这个”思考 → 决策 → 拦截 → 执行 → 反馈 → 再思考”的自动化传送带，就是 Harness 在做的事情。
企业自建 Harness 的”四大天坑”
在 Managed Agents 之前，每个团队都要自己写这个 Harness。常见的工程痛点：
- 状态脆弱：服务器闪断，内存中的执行状态全部丢失
- Token 雪崩：历史步骤不断叠加，上下文消耗呈指数增长
- 死循环失控：模型陷入幻觉反复调用错误工具，瞬间烧光额度
- 安全漏洞：Harness 的网络边界没划清，被提示词注入（Prompt Injection）利用后可能泄露内网数据
Anthropic 的”Managed Harness”就是把这套控制循环做进了云端基础设施，自带熔断、容错、缓存优化，并天然与隔离沙箱和凭证保险库安全连接。
Q: 架构图里的五个组件是怎么协作的？Agent 和 Harness 是什么关系？
整个 Agent 作为最外层的”配置外壳”，包裹住内部五个运行时组件：
┌────────────────────────────────────────────────────────────────┐
│ Agent (智能体外部边界 / 统一配置外壳) │
│ │
│ ┌────────────────────────┐ │
│ │ Tools + Resources / MCP │ │
│ │ (静态工具箱) │ │
│ └───────────┬────────────┘ │
│ │ ▲ │
│ ┌───────────┐ ┌────┴───┐ ┌───────────┐ │
│ │ Session │ <───── │Harness │ ─────> │ Sandbox │ │
│ │(持久账本) │ ─────> │(中枢) │ <───── │(计算沙箱) │ │
│ └───────────┘ └────┬───┘ └───────────┘ │
│ │ ▲ │
│ ┌───────────┴────────────┐ │
│ │ Orchestration │ │
│ │ (大模型大脑) │ │
│ └────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────┘各组件职责：
- Agent（外壳）：静态配置单元，声明使用什么模型、带什么工具箱、在什么环境运行
- Harness（中心）：唯一的流量路由器，拦截模型输出、解析工具调用、驱动沙箱，并把结果追加到账本
- Session（左侧）：独立于模型上下文的分布式事件存储，Append-only（只允许追加）
- Tools / MCP（上方）：工具注册中心，定义可用的 API、内部网关或远程 MCP 服务器
- Sandbox（右侧）：云端完全隔离的容器，运行 AI 生成的不可信代码
- Orchestration（下方）：大模型（LLM），负责高阶推理和决策
类比理解：如果 Agent 是一辆汽车，那么 Orchestration 是司机（做决策），Sandbox 是发动机和车轮（出力），Session 是行车记录仪（记账），Harness 是传动系统和车载电脑（把司机的意图转化为车轮动作，并把路况反馈给司机）。
Q: 传统 Workflow 是人类写代码编排，现在 Agent Orchestration 是 LLM 自己编排——这个理解对吗？
对。这是从”流水线工人”到”项目经理”的转变。
过去的 Workflow 模式：人类用代码写死路由规则——“第一步调接口 A → 结果含关键词 X 走分支 B → 否则走分支 C”。LLM 在链条里只是被动的”文本加工节点”，没有自主权。
现在的 Agent Orchestration 模式：人类退后一步，只提供目标（Goal）、规则边界（System Prompt）和工具箱（Tools）。LLM 升级为”项目经理”，自己拆解任务、决定先后顺序、处理中间错误。编排图变成了动态生成的网状结构，具备弹性和自愈能力。
Q: 如果 Harness 本身挂了怎么办？视频里说的”重新生成一个继续工作”具体是什么意思？
这是 Managed Agents 最震撼的分布式工程设计——无状态 Harness（Stateless Harness）。
传统框架中，Harness 进程的内存保存着”当前执行到第几步”的状态。服务器一挂，Agent 就”脑死亡”了。
Anthropic 的解法是将 Session（独立账本）彻底从 Harness 中剥离并持久化存储：
- 实时记账：Harness 每执行一步，都强行将事件写入独立的 Session 数据库
- 发生崩溃：运行 Harness 的服务器故障，进程消失
- 秒级重生：编排系统立刻在另一台服务器上拉起全新的 Harness 进程
- 无缝接管：新 Harness 通过 Session ID 读取账本——“上个 Harness 执行到了第 8 步，沙箱刚跑完代码，接下来该把结果返回给大脑了”
- 继续推进：从第 8 步无缝接续
来自 YouTube 视频 Anthropic’s Managed Agents Are Different (Here’s Why)（Better Stack 制作）的关键架构点：Session logs are append-only and separate from the harness. The orchestrator creates a new harness if one fails, and because session logs are separate, it can continue where it left off.
对用户而言，这意味着基础设施层面的崩溃被完全屏蔽——前端最多感到极微小的延迟，绝不会遇到”智能体崩溃，请重新输入”。
Q: 面试中有候选人提到，让一个小模型先判断意图再选工具，正确率很高。这个方案放到架构图里是什么位置？
该方案的核心是工具剪枝（Tool Pruning）——在大模型推理前，由一个轻量的小模型（SLM, Small Language Model，如微调后的 7B 参数模型）充当前置意图路由器，从全量工具库中筛选出当前真正需要的少数工具，再传给大模型。
它最合理的定位是嵌入 Orchestration 层内部，形成分层复合大脑：
┌──────────────────────────────┐
│ Orchestration (复合大脑) │
│ │
│ ┌────────────────────────┐ │
│ │ 1. 前置小模型 (SLM) │ │
│ │ 意图识别与工具剪枝 │ │
│ └───────────┬────────────┘ │
│ │ (仅输出工具 ID) │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ 2. 核心大模型 (LLM) │ │
│ │ 参数生成与复杂推理 │ │
│ └────────────────────────┘ │
└──────────────────────────────┘工作流程：Harness 接收到用户请求 → 把历史摘要 + 当前请求发给 SLM → SLM 从 50 个工具中选出 2 个返回 ID → Harness 根据 ID 去 Tools 注册表捞出完整 JSON Schema → 把精简的 Schema 和完整历史拼装成 Payload 发给大模型。
工程价值：大模型看到的上下文极度干净——没有 48 个无关工具的描述干扰注意力，工具选择正确率显著提升。
Q: 多轮对话中用户意图变了，工具集需要更新，SLM 怎么处理？
SLM 不能是”一次性闸门”，必须是每轮动态刷新的过滤器。
假设第一轮用户查了财务数据（使用 Database_Query），第二轮说”把结果做成表格发邮件给 HR”。此时系统的运转：
- Harness 从 Session 读取历史流水（原封不动的完整记录）
- Harness 把历史摘要 + 新请求发给 SLM 重新做意图分类
- SLM 输出新的工具 ID 列表：
["Excel_Generator", "Email_Sender"] - Harness 去 Tools 注册表检索这两个工具的完整 Schema
- Harness 组装最终 Payload 发给核心大模型
关键点：历史流水（messages 数组）原封不动，只有 tools 数组被动态替换。 账本不会错乱。
对于意图漂移，SLM 需要区分两种情况：
- 完全重置：“不查财务了，帮我看 IT 服务器状态” → 清空旧工具，全部换新
- 增量继承：“把财务数据存进数据库，顺便发封邮件” → 工具集做并集
Q: 既然每轮只替换 tools 数组、不改历史流水，那 Prompt Caching 会受影响吗？
会，而且影响是致命的。
这涉及大模型底层的一个”排版潜规则”：大模型接收到 JSON 数据包后，底层网关按固定顺序将其序列化为一整条 Token 文本流：
Anthropic 官方文档明确规定了缓存前缀的创建顺序：
Cache prefixes are created in the following order:
tools→system→messages. This order forms a hierarchy where each level builds upon the previous ones. Changes at each level invalidate that level and all subsequent levels.
由于 tools 被排在最前面，一旦 SLM 在第二轮把工具从”财务工具”换成”邮件工具”：
- 大模型从左往右对比缓存：
[System Prompt]✓ 命中 →[Tools 区]✗ 变了！ - 前缀匹配在此处立即断裂（Cache Miss）
- 后面跟着的所有历史对话——虽然一字没改——由于前缀已被”污染”，全部无法复用缓存，必须重新进行完整的 Prefill 计算
这就是**“准确率 vs. 缓存命中率”的架构悖论**：动态工具剪枝提升了工具选择准确率，但每次工具变动都强迫后续全部历史重新计算。
Q: 有没有办法既保留工具剪枝的准确率，又不破坏 Prompt Cache？
业界（包括 Claude Code、Cursor 等产品的后台架构）通常采用以下三种改良方案：
方案一：工具分桶（Tool Bucketing）
不让 SLM 精准预测单个工具 ID，而是将工具按业务域分成固定的大桶（如”财务桶-20 个工具”、“HR 桶-15 个工具”、“IT 运维桶-30 个工具”）。SLM 只负责判断当前在哪个”业务桶”。只要用户接下来几轮都在聊财务，Harness 发送的 tools 数组就是完全静态的财务桶——既排除了无关工具的干扰，又保证了同域内 Prompt Cache 完美命中。
方案二：子会话派生（Sub-Agent Forking）
主会话保持完全静态、不带具体业务工具的”主路由器”。当意图跨域时，Harness 不修改主会话的 Payload，而是派生一个生命周期极短的子会话。子会话里只有当前几条数据和新工具，虽然没有缓存——但因为它历史极短（Token 量小），Cache Miss 的开销微乎其微。主会话因为工具从未改变，缓存稳如磐石。
方案三：动态成本熔断（Cost-based Thresholding）
Harness 实时监控 Session 的历史长度：
- 对话初期（历史短）：采用动态剪枝，追求绝对准确率——即使缓存不命中，重算代价也低
- 对话后期（历史极长）：触发熔断，停止 SLM 剪枝，锁定当前工具集或转为全量工具模式，全力保缓存
实战权衡：在工业级自动化评测中，指标权重通常是准确率 > 延迟/成本。一个工具误选可能导致整个自动化任务失败，其代价远高于重新计算一次历史文本的算力成本。因此，动态工具替换本质上是”牺牲缓存，换取任务成功率”的典型工程权衡。
参考资料
- Anthropic Engineering Blog: Managed Agents — 官方架构设计文章，详述脑手分离、Session 持久化、凭证隔离等核心机制
- Anthropic Managed Agents Quickstart — 官方快速入门文档
- Anthropic Prompt Caching Documentation — 缓存前缀层级规则的权威来源
- YouTube: Anthropic’s Managed Agents Are Different (Here’s Why) — Better Stack 制作的架构深度解析视频，演示了 Harness 无状态恢复和 Slack 集成
- YouTube: Claude Managed Agents Full Tutorial — 从零配置环境与会话的实战教学