一个durable coding agent harness，应该包含哪些部分？下面是我想到的。工具定义/注册（fs相关的crud工具/bash/pwsh/subagent/agentteam），模型供应，上下文管理（AGENTS.md goal compact loop system prompt tool description tool update)，工具执行的权限系统，工作目录沙盒，Agent Loop，ReAct/Plan mode；以及TUI/GUI，还有btw。我还哪些还没有指出？我的描述可以进行什么改进？

先说结论：你这份清单覆盖面已经不错，但离 durable 还差几块。durable 的判据不是模块齐不齐，而是进程被杀、网断了、人走开半小时、模型换版本之后，任务能不能接着跑并且不重复副作用。按这个判据看，你漏的主要是状态、恢复、验证、观测这几类。 一、没指出的部分 1. 持久化与会话状态。至少两层：完整 transcript（落盘、可 resume）和 working memory（精简、可改写、承载任务连续性）。你写的 compact 是「喂给模型时压缩」，这不是「存下来」。 2. 恢复与对账。session 的状态和真实工作区（git 分支、dirty 文件、worktree）是两套状态，重启后要做一致性对账；有副作用的工具调用要有动作日志，重放时不能重复执行，需要幂等或补偿。这块基本决定 durable 成不成。 3. 审批的异步化。人机协同不能只是卡在终端等 y/n，审批要能作为持久状态排队、通知、稍后批准，否则一断线整个 loop 就死了。 4. 验证层。模型说「做完了」经常是假的，得有 lint、单测、类型检查这类确定性 hook 把失败结果灌回 loop，这同时定义了什么叫 done。 5. 可观测性。每一步的 trace、失败归因、token 与成本统计、replay 调试。没有 trace，跑一小时的失败只能靠猜。 6. 工具链的另外半截。schema 校验、错误包装与重试、结果的截断去噪和重复读取去重、外部工具发现（MCP）。 7. 模型供应的细化。不是接上就完了：多模型路由与降级、限流与并发控制、prompt 前缀稳定性（直接决定 cache 命中率和成本）。 8. 安全面。凭据隔离、网络出口策略、路径逃逸检查，以及把工具输出和网页内容当不可信数据（prompt injection 防御）。 9. 运行中的干预通道。打断、取消、插话（你说的 btw 如果指 agent 干活时插一条侧信道消息，就归这里）、暂停恢复。这块和审批队列是一族的。 10. 接口的多样性。TUI/GUI 之外还有 headless/CI 模式、SDK、远程控制、通知渠道，durable agent 大量时间是无人在场的。 11. 扩展与生命周期。hooks、skills/plugins、MCP server 管理，以及定期复测淘汰失效的 skill 和过时的 workaround。 二、描述可以怎么改 1. 先定判据再列模块。用「没有它，会怎么坏」反推组件，比按模块名平铺更容易看出缺什么。 2. 分层而不是平铺：声明层（system prompt、AGENTS.md、goal、工具 schema），执行层（loop、权限、沙盒），状态层（transcript、memory、checkpoint），观测层（trace、成本），接口层（TUI、GUI、headless）。 3. 你括号里混了粒度。AGENTS.md、goal、system prompt、tool description 都是静态上下文；compact、loop、tool update 是动态过程，建议拆开。 4. 工具定义/注册和执行之间缺一层：schema 校验 → 权限决策 → 沙盒执行 → 结果后处理。权限和沙盒是这层的两个不同问题（该不该做 vs 在哪里做），不该并列。 5. Agent Loop 和 ReAct/Plan mode 不是并列关系。loop 是骨架（调模型 → 跑工具 → 回灌 → 终止条件），ReAct/Plan 只是两种控制策略，同层还有固定 workflow 编排和 subagent 委派。 6. 工具按副作用分级更清楚：读、写、执行任意代码，三类的权限粒度完全不同。 7. 术语上可以再分一下：durable 更偏 runtime 的职责（持久执行、流式、human-in-the-loop），harness 偏一套有主见的现成组装，orchestrator 管的是 runs 之间的事。想清楚你做哪一层，清单取舍会不一样。 三、可以直接对照的现成清单 Raschka 拆的六个组件：实时 repo 上下文、prompt 形状与缓存复用、结构化工具与权限校验、上下文压缩与输出管理、transcript/记忆与恢复、受限 subagent。学术上有个 H=(E,T,C,S,L,V) 的框架：执行环境、工具集成、上下文管理、范围协商、循环管理、验证。另有一篇 harness engineering 的论文把职责列成十一项，包括任务规格、上下文选择、项目记忆、任务状态、观测、失败归因、验证、权限、熵审计、干预记录——你那几个没写到的，基本都能在里面找到对应。