产品边界
`agent-harness` 负责应用级编排和生命周期管理；执行后端负责 agent 执行语义。理解这条分工，有助于判断一项能力该放在哪一层。
边界规则
上游负责 agent 级执行行为，`agent-harness` 负责应用运行时的装配、治理与运维。
稳定的运行时记录
公共接口应该围绕你真正会查询和展示的记录展开，而不是暴露 checkpoint 内部结构。最关键的对象是 requests、sessions、approvals、events 以及它们对应的生命周期动作。
一次请求的基本记录，也是关联和审计的基础粒度。
支撑长链路会话连续性与恢复的持久化上下文。
需要人工决策时使用的稳定记录。
可检查的执行痕迹，不只保留最终回答文本。
为什么公共 API 要保持精简
运行时公共接口应尽量稳定，不跟着 backend 变化一起漂移。适配层可以复杂，但产品 API 不需要暴露这些复杂度。
createAgentHarness(...)
request(...)
subscribe(...)
listRequests(...)
listSessions(...)
listApprovals(...)
resolveApproval(...)
getHealth(...)
stop(...)如果一个提议主要是在镜像 backend 私有状态，或者只是为了暴露适配层细节，那通常不需要进入公共接口。
与上游语义对齐
`agent-harness` 可以在内部做翻译，但不会在外部重新定义一套与上游冲突的执行语义。只要现有执行后端已经定义了某个原语，通常就直接沿用。
更合适的做法
把 backend 相关差异留在 adapter 里，对外只暴露真正稳定的运行时概念。
不合适的做法
为了表面统一，在 harness 层重新发明 memory、graph、checkpoint 或 execution 语义。
如何看待 backend 选择
选择 backend 是 agent 配置决策，不会改变产品本身。无论底下跑的是 deepagent 还是 langchain-v1，审批、恢复和检查能力都还是同一套运行时能力。
- 想用更高层的执行语义时，用
backend: deepagent。 - 想要更轻的 direct-response 路径或明确的 V1 agent 形态时，用
backend: langchain-v1。 - 不要把 backend 细节包装成新的一级产品概念。
对设计的直接影响
这条边界会影响 YAML、文档和测试。YAML 主要表达运行时策略和可复用装配对象；文档先解释用户会接触到的能力；测试则验证稳定记录和生命周期行为。