DeepSeek Harness / 12
Subagent 编排：扩展能力而不是复制 Loop
多 Agent 常被描述成“再启动几个 Agent”。这会快速放大会话、权限、预算、失败传播和上下文隔离问题。更稳妥的设计是把 Subagent 当作一种可选能力，由主运行时决定何时使用，而不是让每个子进程重新发明一套控制规则。
设计理念：一切皆插件，但不是一切都必须启用
从官方架构和社区实践看，可以把 DSH 理解成一个插件化 Agent Runtime：模型、工具、文件系统、Shell、沙箱、会话存储、Subagent、UI，甚至 Loop 本身，都可以成为可替换的能力模块。官方 Web 和 headless 是一套预置 Profile；外部 Profile 和插件可以拼出不同的宿主形态。
这是一种很强的组合能力，也是一种很高的复杂度转移。插件越自由，依赖、权限和版本兼容越难治理，所以“可插拔”不等于“随便加载”。
三种编排责任
| 接缝 | 负责的问题 | 不应取代什么 |
|---|---|---|
ctx.subagents |
发现 provider、检查能力、启动和回收子 Agent | 核心 Agent Loop |
ctx.workflowEngine |
表达依赖、并行和显式工作流 | 隐式的消息拼接 |
ctx.jobs |
管理脱离当前 Turn 的后台任务 | 当前 Turn 的完成状态 |
Provider 的能力应该在启动前检查：是否支持流式、取消、工具、工作目录、审批转发和上下文隔离。能力不满足时提前拒绝，比运行到中途再处理半成品更容易恢复。
自进化的实验性边界
一个值得关注的方向是：Agent 检查当前 runtime，现场编写一个插件并挂载，随后在任务中使用新能力。这已经接近“自进化软件”的雏形，但当前更适合看作实验性能力：动态插件可能只存在于内存，重启后消失，也还没有自动沉淀为经过审查的永久插件。
真正可靠的自进化还需要版本化、权限审批、测试门禁、回滚和来源追踪。能现场写出代码只是能力生成，不等于能力已经获得生产信任。
下一篇建议继续看：Runtime Surfaces：一套运行时如何服务多个宿主