原文链接：https://www.anthropic.com/engineering/managed-agents
关键词：解耦、抽象、故障恢复、多个大脑多个手多段记忆
- 文章以操作系统对底层硬盘的良好抽象为引、将harness比作操作系统、将模型比作为持续演化的硬盘技术和未发布的软件，探讨harness应该如何进行良好的抽象适配不断变化的模型------懂依赖倒置原则的小伙伴应该能明白A÷的想法
- 文章提到A÷之前会把harness的所有内容(包括最重要的session即执行日志)都塞进容器里，但是后来发现这样一旦容器挂掉了，整个harness都会挂掉，这样对整个Harness的故障定位来说十分不方便，所以A÷提出了上图的抽象方法，并列出了这样做的好处：
第一：如果容器挂了，可以重新拉起一个容器，并通过session中的工具执行记录+messages进行环境和上下文恢复，这样容器就成了随时可替换的"畜生"而不是非他不可的"宠物"
第二：在耦合设计中，模型生成的代码会和凭据在同一个环境中，提示词注入可以让模型相对容易地读到凭据并泄露给攻击者。A÷在解耦设计中通过两种方法来保证安全：
1.将凭据本身的生命周期和沙盒的生命周期进行捆绑，这样即使泄露了凭据，危害相对有限，因为沙盒的生命很短暂，攻击者拿到凭据时，凭据大概率已经过期了。（这里是笔者的推断，A÷这里写的不是很详细，感兴趣的小伙伴可以看一下原文）
2.通过MCP将凭据保存在一个和agent的运行环境独立的的环境中，agent可以通过调用MCP来调用工具，而不是直接用凭据来调用工具------当然调用MCP本身也需要鉴权，这里就是操作空间：鉴权时要求鉴权令牌必须和调用MCP的sessionID强绑定，这样鉴权令牌泄露了也没用。
综上其实安全这一块最主要的思路还是 尽可能限制存在泄露风险的令牌或者凭据的使用范围
-
A÷提到可以将未经压缩的上下文，包装为一个可通过代码进行查询的上下文对象，模型可以按需查询之前的上下文。而在解耦架构中，上下文可以存储在Session中，Session模块可以通过暴露getEvent()接口让模型进行灵活的上下文查询，对被查询出的上下文进行进一步组织与处理的工作应该在harness层完成，这样保证getEvent接口是相对不常变的
-
A÷提到解耦架构可以在模型不需要调用工具的情况下，省去容器启动启动带来的时间开销
-
A÷提到解耦架构有个很美丽的特性就是既然"大脑"和"手"解耦了，那么手就变成可以传递的了。未来大脑(笔者理解为决策层，即模型+harness)和手(笔者理解为执行层，即容器+工具)关系可能能从1对N 发展成 N对M。
-
文章还提到，后续模型可能需要能够操纵Session。这里虽然只是简单提到了，但是信息量其实很大，笔者个人理解，应该是指多agent架构下，主agent对于子agent上下文注入方式的革新，比如主agent可以通过将某段session注入给一个子agent，让子agent进行摘要或者是继续完成任务，而不是直接由主agent书写子agent的上下文