Anthropic 近期在 Agent 架构上提出了“Managed Agents”方案，将会话、harness、沙箱虚拟化，号称可以实现组件的独立替换与解耦。然而，仔细审视这套设计，并结合 Claude Code 的实际表现，我们发现其中存在若干值得商榷的问题。以下逐一分析。模型厂商的“屁股决定脑袋”：把工程问题推给模型迭代Anthropic 的工程博客讨论如何构建 Agent 的 harness，其核心思路是：在 harness 中编码关于模型自身无法完成哪些事情的假设。然而他们也承认，这些假设会随着模型能力的提升而过时。问题在于：Anthropic 作为模型厂商，倾向于将一切问题都归结为“模型还不够强”。他们举了一个例子：Claude Sonnet 4.5 存在“上下文焦虑”——感知到上下文窗口快满时会提前结束任务。他们的解决方案是在 harness 里做上下文重置。而当 Claude Opus 4.5 没有这个问题后，重置就成了负担。这个例子看似在说明“假设会过时”，实则回避了一个关键问题：模型的不可预测行为需要工程兜底，而不是等待下一个版本。客户不会因为“Opus 4.5 修好了”就忽略 Sonnet 4.5 上线后几个月内的崩溃。更不用说，Anthropic 自己也承认——超长上下文的后半段模型注意力仍然会衰减。这个问题他们解决了吗？没有。他们只是说“模型能力会提升”。观点：模型厂商的立场天然是“相信模型”，而工程团队的立场是“不相信任何黑盒”。Anthropic 的 Managed Agents 设计从一开始就低估了工程兜底的复杂性，高估了模型迭代的速度和可靠性。因此，一个可靠的做法是：将业务环境和业务场景的不变性约束纳入harness设计，当模型能力变化时，由于这部分硬编码逻辑和业务高度绑定，是业务的代码实现，这部分强制性约束不受模型能力影响。“不要养宠物”是漂亮话，但他们的架构本身就是个精致的笼子