看了 Latent Space 在 10 月 27 日发布的一期访谈，嘉宾是 Anthropic Claude Platform 工程负责人 Katelyn Lesse 和产品负责人 Angela Jiang。两人聊了 Anthropic 如何使用 Claude 开发自己的产品，以及如何构建 Agent 基础设施，涉及 Harness、Sandbox、长期记忆和 Agent Eval 等话题：模型升级后，原来的 Harness 策略是否还适用？当 Agent 开始执行更长、更复杂的任务，系统架构、状态管理和安全边界又该如何调整？

关于作者 Liz: Research AI+社区 Research Fellow，前🐧算法工程师，野生全栈，热爱build，技术E人。专注于将前沿技术落地为真实可用的产品，也喜欢把抽象复杂的技术讲得通俗有趣。欢迎留言交流=D

一、模型升级后，哪些已有设计需要重新检查？

防蒸馏机制，为什么会让 Agent 的 Compaction 失效？

访谈中提到了一个容易被忽略的兼容性问题。

Anthropic 为了限制模型推理轨迹被提取、用于蒸馏，加强了对 Preserved Thinking 的保护。Preserved Thinking 允许模型在后续轮次中继续使用此前生成的 Thinking Blocks。新的保护机制会校验这些推理块的签名，以及它们所依赖的历史前缀是否保持一致。

但是问题来了，一个长时间运行的 Coding Agent，可能在 Context Window 接近上限时主动压缩历史：删除旧的工具输出，把之前的执行过程总结成摘要，再携带必要的历史继续工作。这种 Compaction 策略原本很常见。但如果压缩过程修改了某个保留推理块所依赖的历史内容，新的签名校验就可能使该推理块失效，导致 API 拒绝请求，或者按配置丢弃失效的推理块。

Anthropic 在访谈中提到，部分开源 Harness 和客户原有的 Compaction 实现会受到影响。因此，他们与相关维护者合作，并提供了兼容 Preserved Thinking 的 Compaction 方案。

所以，这个案例提醒我们：当模型的安全机制发生变化，Harness 原有的上下文管理策略是否还适用，也需要重新检查。 过去能够正常工作的 Compaction，如果在压缩历史时修改了保留推理块所依赖的内容，就可能导致校验失败。问题并不是不能再压缩上下文，而是原有的压缩方式可能需要调整，以适应新的安全约束。

这类变化还可能连带影响 Prompt Caching。长任务 Agent 往往依赖缓存减少重复处理历史上下文的成本。但如果安全策略触发模型切换，或者 Compaction 改变了请求的历史前缀，原有缓存就可能无法继续复用。这未必影响任务能否完成，却可能增加延迟和调用成本。因此，调整安全机制或上下文管理策略时，除了检查功能是否正常，也值得关注缓存命中情况和完成整个任务的实际成本。

对于长期运行的 Agent，可以把正常长会话、Compaction 后的长会话，以及触发模型回退的情况放在一起做回归测试，检查这些机制组合之后是否出现了新的兼容性或成本问题。

新模型更强了，旧 Harness 反而可能拖后腿

模型升级后，开发者通常会考虑增加新功能、调整 Prompt，却未必会检查过去积累的 Harness 逻辑还有没有必要。

Anthropic 在另一篇文章《Scaling Managed Agents》中分享过一个例子。他们此前发现，Claude Sonnet 4.5 接近 Context Window 上限时，容易提前结束任务。这种行为被称为 Context Anxiety。为了解决这个问题，团队在 Harness 中加入了 Context Reset。它与普通 Compaction 有一个区别：Compaction 是压缩已有历史，让 Agent 在较短的上下文中继续工作；Context Reset 则会清空当前上下文，通过结构化的任务交接，让新的 Agent 实例接着完成工作。

对于当时的 Sonnet 4.5，Context Reset 能改善长任务表现，但也引入了额外的编排逻辑、Token 消耗和延迟。后来团队切换到 Claude Opus 4.5，发现原来的 Context Anxiety 已经明显缓解，此前加入的 Reset 机制反而失去了必要性。

这就意味着过去有效的 Harness 优化，到了新模型上可能变成技术债。

这在 Agent 开发中可能并不少见。例如，团队为了处理旧模型忘记调用工具的问题，在每次执行结束后强制增加一次检查；为了防止模型偏离任务，在每个阶段都重复注入任务目标；或者为了应对长上下文能力不足，加入大量人工设计的分段和交接逻辑。

这些策略可能改善过原模型的表现，但它们的收益具有模型依赖性。因此，模型升级时可以针对历史 Harness 补丁重新做消融实验。分别测试保留、移除某项策略后的任务成功率、Token 消耗、执行时间和失败类型。如果新模型移除补丁后表现没有下降，甚至有所改善，这段逻辑就值得进一步清理。当然，这主要针对补偿模型行为的启发式策略，不包括权限校验、业务规则和其他必须保留的安全约束。

在 Harness 中增加一段补丁时，最好同时记录它解决了什么失败案例、针对哪个模型版本，以及未来在什么条件下需要重新验证。否则，模型升级几轮之后，维护系统的人可能知道这段代码一直存在，却已经不知道它为什么存在。

AI 重写系统之前，先定义哪些行为不能变

访谈中有一个很有代表性的工程案例：Anthropic 借助 Claude，将 Messages API 的后端实现从 Python 迁移到了 Rust。这次迁移首先来自扩容压力，随着 API 调用量增长，原有 Python 服务的 CPU 开销越来越高，团队希望通过 Rust 改善计算效率。有意思的是，按照嘉宾的说法，当团队决定采用 Rust 时，参与讨论的人里甚至没有 Rust 开发者。

Claude 承担了大量代码实现工作，工程师则主要负责架构设计、迁移计划和验证。据访谈中的估计，这次迁移最终使 CPU 消耗降低了约 40%–50%。不过，这个案例里更值得讨论的是：当 AI 能快速完成大规模代码重写，如何保证新系统没有改变原有的行为？ 对于已经运行在生产环境中的 API，迁移不仅要提高性能，还必须保持已有接口的兼容性。新的 Rust 实现即使能够正常运行、通过单元测试，也不代表它可以直接替代原来的 Python 服务。

Anthropic 在迁移过程中采用了两个方法。首先是控制变更范围。 团队刻意没有借重写的机会增加新功能或大幅调整原有 API 语义。如果一边更换编程语言，一边修改业务逻辑、调整接口行为，后续出现差异时，很难判断究竟是哪项改动引起的。将语言迁移与功能改造分开，可以减少同时变化的因素，也让问题更容易定位。

其次是通过 Shadow Traffic（影子流量）验证新旧系统的行为一致性。 团队构建了新的 Rust 实现，再让新旧系统处理相同请求，比较执行结果。这比单纯依赖代码审查更有价值，因为两种实现可能使用完全不同的内部结构，却需要向外部提供一致的行为。

不过，实际做行为对照时，还需要提前定义比较规则。例如，哪些结果必须严格一致？除了正常响应，错误码、异常处理和边界条件是否也需要比较？对于时间戳、随机 ID 等天然存在差异的字段，应该如何处理？涉及数据库写入、消息发送等副作用时，又如何隔离影子请求，避免测试过程中重复执行真实操作？这些是从迁移案例中可以进一步延伸出的工程要求。

Shadow Traffic 也有局限。新旧实现的结果一致，只能说明它们在已测试的请求下具有行为兼容性，并不能证明旧系统原本就是正确的，也不能覆盖没有进入测试的场景。因此，行为对照之外，还需要保留独立的业务正确性测试。

对于使用 AI 做跨语言迁移、后端替换或大规模重构的团队，这个案例提供了一个很实际的思路：在开始重写之前，先明确哪些行为必须保持不变，并建立能够自动发现差异的验证机制。 AI 可以大幅降低代码实现的成本，但如果没有提前准备验收标准，团队可能很快拥有一套新代码，却无法可靠地判断它能否替换旧系统。

二、 长时间运行的 Agent，如何处理可靠性和安全边界？

Sandbox 挂了，为什么 Agent 还能继续运行？

访谈的另一个核心话题，是 Anthropic 如何把 Agent 的 Brain 和 Hands 分开。早期团队曾采用一种比较直接的架构：将整个 Coding Agent 放进 Sandbox，再通过 API 对外提供服务。这套方案容易实现，但每次启动 Agent 前，都需要先启动 Sandbox 和其中的运行环境，增加了初始延迟。更麻烦的是，Harness、会话状态和执行环境全部绑定在同一个容器中，一旦容器崩溃，整个 Agent Session 也可能随之丢失。

团队后来将它们拆成三个独立部分：

其中 Harness 对应 Brain，Sandbox 对应 Hands。拆分之后，Harness 不再需要和 Sandbox 运行在同一个容器里，只有模型需要执行工具时，系统才调用相应的 Sandbox。如果 Sandbox 崩溃，Harness 可以将其视为一次工具执行错误，交给模型决定是否重试；如果 Harness 自身出现故障，也可以由新的实例读取持久化的 Session Log，从已有的事件记录继续执行。

这套设计还有一个重要的变化：Session 不再等同于模型当前的 Context Window。 一项任务可能运行很长时间，期间经历多次 Compaction，甚至切换多个模型上下文。如果 Session 是独立的事件记录，Harness 就可以根据当前需要，从历史中选择相关事件交给模型。较早的上下文即使不再出现在 Prompt 中，也不意味着它已经从系统中永久丢失。

不过，恢复 Session 不等于自动恢复 Sandbox 里的所有进程、内存变量和临时文件。对于具有外部副作用的工具，还会遇到一个经典的分布式系统问题：假设 Agent 已经成功向数据库写入数据，但还没将工具结果保存到 Session Log，进程就崩溃了。恢复之后，系统可能无法确定刚才的写入是否成功。如果直接重试，就有可能重复执行相同操作。

这种情况下，需要通过幂等键、外部状态查询或操作确认机制处理，而不能把所有失败都视为可以无条件重试。因此，长任务 Agent 的可靠性测试可以加入故障注入：分别在工具调用前、工具执行后，以及结果尚未持久化时主动中断执行，检查系统能否恢复正确状态。

当然，并不是每个 Agent 都需要如此复杂的架构。对于执行时间很短、没有复杂状态或外部副作用的任务，将运行逻辑放在一起可能更简单。当任务需要跨越多个执行环境、经历故障恢复或长期保存进度时，独立持久化 Session 的价值才会更加明显。

不给 Agent API Key，它如何调用外部服务？

Brain 和 Hands 分离还带来了一项安全收益。访谈中提到，Anthropic 最初设计这套架构时，主要考虑的是延迟和可靠性，后来才越来越重视它带来的安全隔离效果。此前，如果 Agent 的执行代码和服务凭证都存在于同一个容器，模型生成的不可信代码就可能接触这些凭证。即使在 Prompt 中明确禁止泄露，一次成功的 Prompt Injection 仍可能诱导 Agent 读取环境变量或配置文件中的敏感信息。

Anthropic 采用的方式是将凭证与执行环境隔离。例如，把外部服务的 OAuth Token 保存在 Sandbox 之外的 Vault 中，由 Proxy 取得相应凭证并完成工具调用。这样 Agent 仍然可以访问外部服务，但运行代码的 Sandbox 不需要直接持有凭证。配合网络出口限制，可以进一步缩小不可信代码能够访问的资源范围。

但凭证隔离并没有解决所有权限问题。假设一个 Proxy 保管了数据库管理员凭证，Agent 虽然无法直接读取密码，却可以通过 Proxy 提交任意 SQL，那么即使凭证没有泄露，Agent 仍然可能执行超出任务范围的操作。因此，代理层除了保护凭证，还需要校验操作权限，包括允许访问哪些资源、可以执行什么操作，以及当前任务是否具有相应授权。

这一问题也开始被云平台纳入 Agent 的身份与权限管理体系。例如，Google Cloud 在 2026 年推出了 Agent Identity，让 Agent 能够拥有独立身份，并通过 IAM 管理其访问权限。与传统使用 Service Account 的方式相比，这种设计将 Agent 本身作为独立的权限主体，而不只是让它共享某个后台服务的身份。

Google 的身份委托架构还进一步区分了 User Identity、Agent Identity 和 Delegated Identity。这里有一个重要问题：Agent 究竟是在以自己的身份执行任务，还是在代表某个用户操作？ 如果是后者，授权就需要同时考虑 Agent 自身的权限约束，以及用户授予的权限和 OAuth Scope。例如，一个员工让 Agent 查询企业数据，不能仅因为后台服务拥有更高权限，就允许 Agent 访问该员工原本无权查看的资源。

当然，独立的 Agent Identity 也不会自动解决所有越权问题。如果下游工具仍然接受任意操作，或者 Proxy 没有正确执行授权检查，Agent 依然可能通过合法接口完成未经授权的行为。对于企业 Agent 或 MCP 工具，除了验证身份，还需要在实际执行层落实资源范围、操作类型和数据访问权限，并通过越权测试确认这些限制确实生效。

所以，Agent 的安全设计除了考虑如何保护 API Key，还需要明确三个问题：谁在执行任务、代表谁执行，以及被允许执行哪些操作。 当 Agent 开始访问企业数据库、SaaS 系统和其他外部工具时，这些权限边界需要由基础设施和工具接口来保证，而不能只依赖 Prompt 约束。

三、长期记忆、多 Agent 和 Eval，还能怎样设计？

让另一个 Agent 整理记忆，会不会把错误也整理进去？

长期运行的 Agent 会不断积累记忆，但这些记忆不一定始终准确。例如，一个研究 Agent 在数月内参与同一个项目，记录了不同版本的实验假设、数据结果、失败经验和项目约束。随着信息增加，记忆库可能出现大量重复内容，更麻烦的是，一些早期结论已经被后续实验推翻，却仍然保留在记忆中。

访谈中提到了一种处理方式：启动另一个 Agent，检查已有记忆和历史会话，对重复、过时或矛盾的信息进行整理。Anthropic 将这种机制称为 Dreaming。整理结果可以保存在独立的记忆版本中，供开发者检查后再使用。这个思路并不复杂，但它引入了一个新的可靠性问题：负责整理记忆的 Agent，如何判断历史信息是否仍然有效，又如何保证自己没有改变原始信息的含义？

比如，某个实验最初提出了一项假设，后续测试只提供了部分支持。如果整理 Agent 为了压缩信息，省略了实验条件和不确定性，最后留下的记忆就可能把假设写成已经验证的结论。还有一种情况是，新旧信息看起来相互矛盾，实际上只是适用于不同条件。例如，两个实验使用了不同版本的数据集，结论也不同。如果整理时简单地用新记录覆盖旧记录，反而会丢失重要的研究过程。

因此，评价长期记忆整理时，不能只看重复内容减少了多少，或者记忆库压缩了多少。对于需要长期运行的 Agent，可以进一步比较整理前后的任务完成率、过时信息引用率和错误记忆发生率，同时检查重要结论能否追溯到原始 Session 和对应证据。这样才能判断记忆整理有没有改善 Agent 后续的表现，而不只是让 Memory Store 看起来更整洁。

此外，记忆整理本身也需要消耗计算资源。对于只执行一次的任务，复杂的长期记忆维护可能没有必要；但对于持续数月、需要反复使用历史信息的 Agent，记忆的准确性和维护成本就值得单独评测。

Verifier、Memory、Multi-Agent，哪些应该成为 Harness 的核心能力？

在讨论 Managed Agents 时，Anthropic 的嘉宾提到了一个架构选择：希望基础 Harness 保持相对简单，把更多优化策略放在上层实现。例如，Dreaming 可以作为独立 Agent 运行，负责整理另一个 Agent 的记忆；类似的方式也可以用于 Verifier Agent、Best-of-N，以及多个 Agent 并行探索的任务。这些能力可能改善系统表现，但不一定需要全部写进核心 Harness。

这里涉及一个更普遍的设计问题：当 Agent 系统不断增加新能力，哪些应该成为 Runtime 的基础功能，哪些更适合作为可替换的上层策略？

Session 持久化、工具执行、状态恢复和权限控制，通常属于底层运行环境需要提供的基础能力。Verifier、Memory 整理和 Multi-Agent 协作则更多是在这些基础能力之上，为改善任务质量或效率而增加的策略。例如，Verifier Agent 可以独立检查主 Agent 的输出，Memory Agent 可以定期整理历史，多个执行 Agent 则可以并行搜索不同方案。它们依赖相似的底层能力，却有各自的执行流程和评测方法。

如果把某一代模型适用的优化策略全部固化到 Runtime，模型升级或任务变化后，系统可能需要频繁修改核心逻辑。把这些策略作为独立组件，则更方便替换实现、开展消融实验，或者针对不同工作负载选择不同方案。不过，模块化也有成本。更多独立 Agent 意味着更多模型调用、状态传递、任务协调和结果合并；如果各个组件还需要自行处理重试、权限和状态管理，过度拆分也可能导致重复开发。

尤其是 Multi-Agent，并行执行并不一定带来更低的端到端延迟。如果几个 Agent 需要频繁共享中间状态，或者一个 Agent 的工作依赖另一个 Agent 的结果，协调成本就可能抵消并行收益。这里还需要区分另一种情况：Multi-Agent 系统表现更好，究竟是因为任务分工合理，还是因为它消耗了更多计算资源？

例如，四个 Agent 使用了单 Agent 三倍的 Token，最终得到了更好的结果。这说明增加计算资源可能有效，却还不能证明 Multi-Agent 的组织方式本身更高效。可以进一步在相同计算预算下比较任务质量，或者比较达到同等质量时，两种方案分别需要多少成本和完成时间。（Multi-agent v.s. Single agent我在这篇文章中也讨论过：https://mp.weixin.qq.com/s/-MhL-Liu6Ng1LzJaw_isEA）

因此，基础 Harness 是否应该保持简单，不能只看模块划分是否清晰，还要看哪些能力需要被不同策略反复使用，以及拆分之后是否真的降低了系统演进和实验的成本。

Agent 没通过 Eval，到底是模型、环境还是测试出了问题？

访谈后半段讨论了 Agent Eval。Anthropic 的嘉宾提到，很多 Agent 开发者对评测的投入仍然不足。有些团队已经在使用 Agent 处理复杂任务，却没有积累足够的测试案例；另一些团队则花费大量时间研究评测框架，实际运行的 Eval 却很少。她们建议先从简单的评测开始，根据真实任务中发现的问题逐步增加覆盖范围。

其中有一段讨论，我觉得特别值得研究者和工程师关注。主持人提出，Agent Engineering 正在越来越像实验研究：先定义目标，尝试将目标转化为可测量的 Eval，再观察运行结果、分析失败原因，决定下一轮应该修改什么。但在这个过程中，Eval Failure 不一定意味着 Model Failure。 有时候是模型没有完成任务，有时候是运行环境出了问题，还有时候是 Eval 本身没有正确衡量目标。

这在 Agent 场景中尤其常见。假设一个 Agent 需要检索数据、调用 Python 分析，再生成研究报告。最后报告没有通过评测，可能是模型选择了错误的分析方法，也可能是工具运行时缺少依赖、中间数据没有正确传递，或者报告本身符合要求，但评测脚本只检查了固定的输出格式。如果只看到最终的 Pass/Fail，就很难判断应该修改 Prompt、Harness、工具环境还是评测标准。

因此，除了最终任务结果，Agent Eval 还需要足够的过程信息来帮助定位失败。例如，记录关键工具调用、执行环境错误、中间产物和重试情况，再结合最终的任务验收结果，判断错误究竟发生在哪个环节。对于可以确定验证的部分，例如测试是否通过、文件是否生成、数据库状态是否正确，可以优先使用确定性检查；开放式任务则可以结合 LLM-as-a-Judge 和人工反馈。

不过，LLM-as-a-Judge 也有自身的局限。模型可以帮助生成测试案例、阅读执行轨迹和分析失败原因，但如果生成者与评判者共享相同的盲点，就可能出现看似合理、实际却不准确的评分。因此，评测标准本身也需要验证，不能因为评分过程由模型自动完成，就默认它能够正确衡量任务质量。

这一点其实和前面几个问题相互关联。模型升级后，Harness 补丁是否仍然有效，可以通过消融实验验证；Session 和 Sandbox 解耦之后能否正确恢复，可以通过故障注入验证；增加 Verifier 或多个 Agent 后，额外计算有没有带来足够收益，也需要任务级 Eval 来比较。

如果无法定位失败原因，就很难判断一次系统优化到底有没有效果。对于 Agent 系统而言，Eval 的价值不仅在于给结果打分，还在于为后续的工程决策提供依据。

最后：Agent 工程需要不断重新验证自己的设计

整理完这八个问题，我发现其中有两类不同的工程工作。一类是随着模型能力变化，不断检查已有策略是否仍然有效。例如，旧模型需要的 Context Reset，到了新模型上可能已经没有必要；推理块的安全约束发生变化后，原有 Compaction 策略也可能需要修改。这些设计与模型当前的行为紧密相关，需要随着模型迭代重新验证。

另一类是建立更稳定的系统边界，让模型和执行策略能够独立演进。例如，Session 独立于 Context Window，Harness 独立于 Sandbox，凭证独立于执行环境。这些设计主要解决状态管理、故障恢复和权限控制的问题。在这些基础能力之上，Memory、Verifier 和 Multi-Agent 等策略又可以根据任务需要分别优化。

这场访谈给我的一个启发是，Agent 工程中的很多问题，其实可以回到已有的软件工程和实验研究方法中寻找答案：通过消融实验判断历史补丁是否应该删除，通过故障注入验证恢复逻辑，通过权限测试检查安全边界，通过任务级 Eval 比较不同策略的实际收益。

随着模型能力提高，Agent 能够承担越来越复杂的工作，工程师也需要不断重新判断哪些设计仍然必要，哪些复杂度可以删除，哪些问题应该交给更稳定的基础设施处理。这些判断没有必要照搬某家公司的实现，更重要的是理解它们为什么这样设计，再结合自己的任务和工作负载去验证。

加入我们

JOIN US

扫码关注公众号

加入读者群

👋 Research AI+是一个面向青年研究者的 Global开放社区。我们汇聚了AI 、AI for Science/Engineering、Physical AI 方面的众多优秀学者、科研工作者、产业界研究员、工程师、AI项目开源贡献者和Tech Founders。是一个站在学术、产业与创业交叉点的创新型开源社区。

🍻我们日常会有前沿技术分享、闭门讨论会、Tech meetup、Research Party 等有意思的社区活动，希望通过高质量的社区活动和内容来促进科研、工程、技术的交流和进步！

👀社区有自己的媒体，会经常分享前沿科研工程内容和高质量的技术活动资讯，同时我们也会深度报道值得被关注的研究者、工程师、技术创业者，欢迎优秀的工作和团队来稿～也欢迎关注我们！