OpenCLI 学习 03：Agent 边界与设计张力

1. Agent 和 harness 的边界

这是我在理解过程中非常关键的一点。

当前我的理解：

• Agent 负责“决定做什么”
• Harness 负责“把事情做成可调用能力”

也就是说：

• Agent 更像策略层、决策层、编排层
• Harness 更像能力层、执行层、适配层

Harness 本身不是 Agent，它更像是 Agent 可调用的工具系统。

2. 这个项目的反馈机制属于哪一类

我之前会自然想到“自我反思型”的 harness：

• 会自动评估自己做得好不好
• 会自动调整策略
• 会自动重规划

但这个项目里的 harness 并不强内建这种运行时自我反思。

它更强的是：

• 可观察：info、list、status、history
• 可验证：真实输出检查、E2E 测试、validate
• 可增量改进：refine

所以这里更像是“工程化反馈闭环”，而不是“自主智能反思闭环”。

3. 我对 checkpoint 的当前理解

这个项目里没有特别统一、显式的 checkpoint 系统。

但从 Agent 使用视角看，checkpoint 实际上分散在这些地方：

• 任务前：Skill 告诉 Agent 这个 harness 适合什么任务
• 任务中：info/list/status/json 告诉 Agent 当前状态是什么
• 任务后：输出文件验证、测试、validate 告诉 Agent 结果靠不靠谱

所以 checkpoint 不是单独模块，而是由“多个可观察节点”共同实现的。

4. 这个项目背后的设计张力

我觉得这个项目最有意思的地方，是在平衡“模糊性”和“确定性”。

如果完全交给 Agent：

• 灵活
• 泛化强
• 但过程模糊，不稳定

如果完全写死流程：

• 稳定
• 可控
• 但会很死板

这个项目选择的是中间路线：

• 把底层操作标准化、确定化
• 把高层任务策略留给 Agent

5. 我目前最认可的一句话

这个项目固定的是能力接口，不固定的是任务策略。

或者说：

它不是把任务流程完全固定，而是把底层操作标准化，让 Agent 在可控边界内自由编排。

6. 为什么我觉得这个点很重要

因为这解释了：

• 为什么需要 Skill
• 为什么需要命令树
• 为什么要有 --json
• 为什么要有 status/info/list
• 为什么还要有 validate/refine

它们一起在做的事情，就是让 Agent 在不被完全写死的前提下，依然能可靠调用软件能力。

7. 当前阶段的总认识

这个项目不是追求“让 Agent 自己在黑盒中涌现完成一切”，而是先由人进行大量具体施工，把软件能力整理成结构化、可观察、可验证的接口，然后再交给 Agent 使用。