OpenCLI 学习 07：我的工作方向与方法抽象

1. 我目前开始形成的一个工作判断

我觉得之后我的工作可以分成两个主要方向。

方向一：构建一个聪明且通用的 Agent

这个 Agent 的重点，不是把所有具体业务逻辑都写死在内部，而是让它擅长：

• 理解任务
• 选择工具
• 读取状态
• 逐步决策
• 失败后调整
• 结合 Skill 和结构化输出来完成多步编排

也就是说，它更像是一个通用的编排和判断层。

方向二：把具体业务需求落成 Agent-Friendly Harness

当一个具体业务需求到来时，我不再优先想着：

• 直接暴露零散 API
• 直接写一个固定 workflow

而是优先考虑：

• 能不能把这类业务能力整理成命令树
• 能不能有清晰的状态模型
• 能不能有结构化输出
• 能不能让 Agent 更容易识别这些能力并自主组合

也就是说，重点从“写固定流程”转向“设计能力接口”。

2. 一个重要修正：不是不要 API，而是不要把 API 直接等同于 Agent 接口

我当前逐渐意识到：

• 底层仍然可以有 API、SDK、数据库、第三方服务
• 但 Agent 不一定应该直接面对这些底层接口

更合理的分层可能是：

• 底层：API / SDK / service
• 中层：CLI-harness / 命令树 / 状态模型
• 上层：Agent 编排

所以不是否定 API，而是提升一层抽象后再给 Agent 使用。

3. 为什么这种分层有价值

我现在觉得，这种方式的一个很大好处是：

• 把 Agent 设计和具体业务能力落地相对解耦

这样就可以：

• 先做一个通用 Agent
• 再把具体业务逐步落成不同 harness
• 最后形成“通用 Agent + 领域 harness”的组合

它不一定天然完美，但会比把所有逻辑都揉在一起更清晰、更可替换、更容易演进。

4. 这里最难的地方不在于“写几个命令”

我目前觉得真正难的点在于：

• 哪些能力应该暴露
• 命令如何分组
• 命令粒度多大最合适
• 哪些状态必须显式暴露
• 如何降低 Agent 的理解成本
• 如何让 Agent 既有自由度又不至于乱用能力

所以真正的难点是 Agent 和 harness 之间的接口设计，而不是单纯的代码实现。

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

我的工作将分成两层：

• 上层做通用 Agent
• 下层做面向具体业务的 harness

前者负责思考和编排，后者负责把业务能力整理成 Agent 可理解、可调用的结构化接口。