AI Agent 工作流实践：从 Claude Code、Codex 到 OpenClaw、Hermes 与 DeepSeek

Posted on 2026-09-23 In AI 与 Agent

从任务判断、Agent 与模型选择，到编码、个人助理和自动化实践的一套工作流。

AI Agent 工作流实践：从 Claude Code、Codex 到 OpenClaw、Hermes 与 DeepSeek

引言：我不是在选择一个聊天机器人

最近一段时间，我使用 AI 工具的方式发生了变化。

以前更像是在问：“哪个模型写代码更好？”现在我更常问的是：

这件事到底需要哪一种 Agent？它应该拥有多大的权限？哪个模型适合承担这一步？最后用什么证据证明它做对了？

这是一个很重要的转变。Claude Code、Codex、OpenClaw 和 Hermes 并不处在完全相同的产品层级；DeepSeek 也主要是模型和 API 提供商，而不是一个完整的工作流 Agent。如果把它们放在一张“谁更强”的排行榜上比较，通常会得到一个没有实际指导意义的答案。

我更愿意把它们看成一组可以组合的工作部件：

Claude Code 和 Codex 更适合围绕代码仓库工作。
OpenClaw 和 Hermes 更适合做长期运行的个人助手、消息入口和自动化网关。
DeepSeek 更适合作为某些 Agent 的模型后端，用于成本、延迟或中文任务方面的权衡。

本文不是五个产品的百科介绍，而是我目前更认可的一套实践框架：先判断任务，再选择 Agent；先判断任务难度，再选择模型；最后把权限、上下文、验证和复盘组成一个完整闭环。

文中会区分三种内容：官方文档明确说明的能力、我从原有实践中保留的经验，以及需要在自己的环境中重新验证的结论。产品更新很快，命令、模型名、价格和支持范围都不应该被当成永久事实。

一、先选择工作流，再选择 Agent

1.1 Agent 和模型不是一回事

一个完整的 Agent 工作流至少包含下面几层：

任务目标
   ↓
Agent 工作面：会话、状态、工具、权限、记忆、调度
   ↓
模型：理解、推理、生成、工具参数选择
   ↓
领域服务：代码仓库、数据库、搜索、消息、支付、部署系统
   ↓
验证与治理：测试、审批、审计、回滚、评测和成本控制

模型负责生成下一步决策，但它不应该直接成为业务事实的唯一来源。Agent 负责把模型放进一个可以运行的环境中，并处理上下文、工具、状态和权限。真正的业务系统仍然应该负责库存、订单、权限、支付、部署等确定性约束。

因此，DeepSeek 可以替换一个 Agent 使用的模型，但它不会自动替代 Agent 的会话、权限、工具和验证机制。反过来，OpenClaw 或 Hermes 可以接入不同模型，但它们仍然需要解决消息路由、长期记忆和后台任务的问题。

1.2 先问任务的边界

在启动任何 Agent 之前，我会先回答八个问题：

最终要交付的是代码、报告、消息、配置，还是一个持续运行的任务？
Agent 需要读取哪些资料？哪些资料绝对不能读取？
它是否需要写文件、执行命令或调用外部服务？
操作是否有不可逆的副作用？
任务是否需要跨会话记忆、定时执行或从手机/聊天软件触发？
出错时谁承担成本？是返工几分钟，还是数据损坏、错误部署或错误发信？
成功的判断标准是什么？测试、构建、人工确认、业务指标还是用户反馈？
任务结束后，哪些经验值得沉淀为规则或技能？

这八个问题比“我现在应该用哪个模型”更重要。因为如果任务边界没有定义清楚，换一个更强的模型通常只会让错误执行得更快。

1.3 我的 Agent 选择矩阵

工作类型	优先考虑	我会关注什么
理解仓库、修改代码、运行测试、审查 diff	Claude Code / Codex	文件和命令权限、项目规则、工作区隔离、验证闭环
需要脚本化、CI 或非交互执行	Codex / Claude Code CLI	是否能稳定运行、输出是否可解析、失败是否可重试
需求拆解、长任务规划、复杂调试	Claude Code / Codex	计划质量、上下文管理、子任务拆分、人工检查点
个人消息入口、技能路由、长期助手	OpenClaw / Hermes	Gateway、渠道、记忆、技能权限、后台任务和审计
定时报告、个人资料整理、跨渠道通知	OpenClaw / Hermes	调度可靠性、重复执行、消息发送权限和失败通知
模型后端替换、成本优化、批量推理	DeepSeek 或其他模型 API	兼容协议、工具调用、延迟、限流、价格和质量回归

这不是排他性的选择。例如，我可以用 Codex 修改代码，用 DeepSeek 做一批低风险的文本分类，再用 OpenClaw 把结果发送到指定渠道。但我不会让一个聊天 Agent 同时掌管代码、生产数据库和外部消息发送权限。

二、我的七步 Agent 工作流

2.1 第一步：写清楚目标和禁止事项

我会把需求写成一个短的任务协议，而不是一句“帮我做一下”。一个实用模板如下：

## 目标
在 `src/orders/` 中增加订单状态查询能力。

## 输入与输出
- 输入：订单 ID 和当前用户身份
- 输出：脱敏后的订单状态和最近一次状态变化

## 约束
- 复用现有鉴权中间件和订单领域服务
- 不直接访问数据库表
- 不修改支付和退款逻辑
- 不新增未经确认的外部依赖

## 验收标准
- 正常、未授权、订单不存在三类用例都有测试
- 运行现有 lint、单元测试和构建
- 最后输出修改文件、测试结果和未解决风险

这和我在 Spec Coding 文章中讨论的思路是一致的：规范不是给 Agent 增加形式负担，而是把人的意图变成可检查的输入。相关背景可以参考规范驱动的 AI 编程。

2.2 第二步：先加载上下文，再给具体任务

上下文不是越多越好。我的做法是先让 Agent 找到正确的事实来源：

先不要修改文件。
请阅读项目规则、目标目录、同类实现和现有测试，回答：
1. 当前实现采用了什么模式？
2. 哪些文件是这次任务真正需要修改的？
3. 有哪些约束或潜在风险？
4. 你建议如何验证？

复杂需求可以先让 Agent “采访”我：让它逐个追问用户、权限、失败模式、并发量、数据边界和验收标准。采访结束后再整理成 Spec，最好用新的会话执行，避免讨论过程中的大量试探信息污染执行上下文。

我会优先提供：

项目规则文件，例如 AGENTS.md 或 CLAUDE.md；
目标目录和少量相关文件，而不是整个仓库；
真实错误日志、截图、接口样例和失败测试；
已有的正确实现，让 Agent 模仿项目内部模式；
明确的“不要做什么”。

2.3 第三步：先计划，后执行

计划阶段至少要回答：

会修改哪些文件？
每一步依赖什么？
哪些步骤可能产生副作用？
如何验证每一步，而不是最后才统一验证？
如果中途失败，能否从某个检查点恢复？

计划不是让 Agent 写一篇漂亮的设计文档，而是让执行变得可观察。计划过大时，我会拆成多个独立任务；每个任务都应该有自己的输入、输出和验证方式。

2.4 第四步：控制权限和工作区

我把权限看成工作流的一部分，而不是安装时的一次性配置：

只给当前任务需要的目录和命令权限。
代码修改尽量在独立分支或 worktree 中进行。
生产写操作默认需要人工确认。
API Key、Cookie、个人资料和内部日志不直接放入 Prompt。
外部消息、删除、部署、支付和数据迁移都要单独设置审批点。

Agent 越强，权限边界越重要。自动接受所有操作并不等于自动化成熟；成熟的自动化应该能够说明它做了什么、为什么做、失败后如何恢复。

2.5 第五步：让 Agent 执行最小可验证动作

我不喜欢一次给出一个跨越十几个模块的大任务。更稳妥的节奏是：

1	读取 → 计划 → 小步修改 → 测试 → 检查 diff → 下一步

如果是批量任务，也会先让 Agent 在一个样本上运行，确认结果后再扩大范围。对外部工具调用则先使用只读或 dry-run 模式，确认参数和范围之后再允许写入。

2.6 第六步：用证据验证结果

“Agent 说完成了”不是验证结果。我的最低验证层级通常是：

文件和 diff：是否只修改了应该修改的内容？
静态检查：格式、类型、lint、schema 是否通过？
单元测试和集成测试：正常、失败、边界和权限场景是否覆盖？
构建或启动：真实运行链路是否可用？
人工抽查：关键业务规则、数据权限和用户体验是否正确？
运行指标：延迟、成本、错误率、工具成功率和用户反馈是否改善？

对于模型或 Agent 的比较，我不会只看单轮回答。至少准备一组自己的任务集，记录成功率、工具调用成功率、返工次数、P50/P95 延迟、Token/费用和失败类型。

2.7 第七步：把经验沉淀成系统能力

每次遇到相同错误，我都会判断它应该被放在哪里：

经验类型	适合沉淀的位置
所有任务都适用的项目规则	`AGENTS.md` / `CLAUDE.md`
可重复的多步流程	Skill 或脚本
每次提交都必须执行的检查	Hook、CI 或 pre-commit
外部系统的标准工具接口	MCP 或内部 API
用户偏好、长期事实和历史决策	经过审核的知识库
单次任务的临时信息	当前会话，不要永久保存

这也是 Harness Engineering 的核心：不要只优化 Prompt，而要把上下文、约束、工具、验证和可观测性一起设计。相关内容可以参考书稿第 16 章 Harness Engineering。

三、如何选择模型

3.1 我关注的不是模型排行榜

模型选择应该跟任务特征绑定。我会从下面六个维度判断：

维度	需要观察的问题
推理深度	能否处理多步骤约束、反例和权衡？
代码能力	能否理解项目内部模式，而不是只生成孤立代码？
工具调用	参数是否正确？失败后是否能恢复？会不会重复产生副作用？
上下文能力	长任务中是否能保留关键约束？是否需要图片或网页信息？
成本与延迟	是否适合交互、批处理或长时间运行？
数据边界	数据是否离开本机？供应商是否保留日志？是否可以自托管？

3.2 我的模型路由规则

复杂架构、生产故障、高风险修改：选择能力最强且工具调用稳定的模型，保留人工审查。
简单重构、格式迁移、批量生成：选择更快、更便宜的模型，先在小样本上验证。
工具密集型任务：优先结构化输出、参数遵循和失败恢复能力，而不是单轮文采。
中文资料整理和本地知识任务：用自己的中文数据集测试召回、总结、引用和事实一致性。
私密数据任务：优先考虑数据是否能留在受控环境中，不因为价格低就跳过安全审查。
长任务：如果模型容易丢失约束，先拆任务、压缩上下文或改用状态机，不要只提高上下文窗口。

模型选择的一个常见误区是只测试“请写一段代码”。真正影响工作流的，往往是：它能不能先读懂项目、能不能在错误后修正、能不能正确调用工具、能不能在不确定时停下来询问。

四、Claude Code：把终端变成编码工作面

4.1 官方能力边界

Claude Code 官方文档将它描述为 Agentic Coding Tool：可以读取代码库、编辑文件、运行命令，并连接开发工具；当前提供终端、IDE、桌面和 Web 等工作面。官方文档还列出 MCP、指令、Skills、Hooks、并行 Agent、CLI 脚本化和定时任务等扩展方式。

这意味着 Claude Code 不只是一个代码补全插件。它更像一个围绕项目上下文运行的终端 Agent：先观察环境，再选择工具，再修改文件和运行命令。

官方入口：https://code.claude.com/docs/en/overview

4.2 我的使用方式：Plan → Execute → Verify

对于复杂任务，我会把会话分成三个阶段：

Plan：只理解和设计

1
2
3

先不要修改代码。
请读取 AGENTS.md、目标目录、相关测试和同类实现。
输出：现状、方案、文件清单、风险、验证命令和需要我确认的问题。

Execute：一次只推进一个可验证步骤

1
2
3

按照已确认的计划完成第 1 步。
修改后运行对应测试，并告诉我：改了什么、测试结果是什么、还有哪些风险。
不要顺手重构无关代码。

Verify：把结果交回证据

1
2
3

请检查当前 diff。
运行与本次改动相关的测试、lint 和构建。
最后按“通过项 / 失败项 / 未覆盖风险 / 建议下一步”输出。

这个流程的价值不在于三个英文单词，而在于把思考、执行和验收分开，减少“边改边猜”的上下文污染。

4.3 CLAUDE.md、Skills、Hooks 和 MCP

CLAUDE.md 适合记录 Agent 无法仅从代码推断出的项目知识，例如：

如何启动和测试项目；
哪些目录不能修改；
哪些命令需要人工确认；
项目采用的架构和命名约定；
发生某类错误时应该先检查什么。

我不会把整个项目百科都塞进去。一个有效的规则文件应该是入口地图：告诉 Agent 去哪里找事实，而不是复制所有事实。

Skills 用来封装可复用的工作流，例如“审查一篇文章”“新增 API”“生成迁移计划”；Hooks 用于把关键检查机械化；MCP 适合连接外部服务，但每个连接都应有清楚的权限、数据范围和失败处理。

4.4 会话管理和并行工作

上下文快满时继续追加信息，往往比重新开始一个干净会话更糟。我会在以下情况下清理或新开会话：

任务目标已经改变；
前一个任务的错误信息会干扰当前判断；
计划已经稳定，需要一个干净上下文执行；
长任务已经被拆成多个独立子任务。

多个 Agent 并行时，必须隔离工作区、明确边界和定义合并方式。并行不是把同一批文件交给多个 Agent 同时写，而是让它们处理互不冲突的调查、测试或实现任务。

4.5 Claude Code 适合和不适合什么

适合：

需要读懂已有代码后跨文件修改的任务；
需要执行本地命令、测试和构建的任务；
需要持续对话、反复审查和逐步修正的任务；
需要通过 Skills、Hooks、MCP 适配团队流程的任务。

不适合直接承担：

没有验收标准的“自由发挥”；
没有权限隔离的生产写操作；
依赖最新外部事实却没有开启搜索或提供来源的研究；
需要强事务、强一致性而又没有领域服务保护的业务操作。

五、Codex：仓库优先、权限可控的开发 Agent

5.1 官方能力边界

Codex CLI 官方文档的核心描述很明确：在终端中检查代码、修改文件、运行命令和自动化重复工作。它支持在项目目录中理解代码、制定计划、执行本地工具、查看 diff，并可以通过权限模式控制 Agent 能做什么。

官方示例还展示了 /init 创建 AGENTS.md、/status 查看会话状态、/permissions 选择权限、/model 选择模型和推理力度，以及 /review 对未提交变更、提交或基线分支执行代码审查。Codex 还可以通过 Skills、Plugins、MCP、子代理、非交互命令和云端工作面扩展。

官方入口：https://learn.chatgpt.com/docs/codex/cli

5.2 我的使用方式：让仓库规则成为共同上下文

我会把项目级规则写入 AGENTS.md，而不是只在某一次对话里重复说明。一个最小入口可以包含：

# Repository Rules

## Before editing
- Read the relevant source and tests first.
- Do not edit generated output.
- Preserve unrelated user changes.

## Verification
- Run the targeted test before broad tests.
- Inspect `git diff` before reporting completion.
- Report failures and uncovered risks explicitly.

## Safety
- Do not expose secrets.
- Ask before destructive or external side-effecting actions.

启动任务时，我倾向于先这样说：

1 2	先阅读 AGENTS.md 和目标模块，不要修改文件。给出当前实现、建议方案、风险和验证命令。

确认计划后，再让它执行；完成后使用 /review 或等价的变更审查流程检查结果。

5.3 Codex 和 Claude Code 的选择

我不会根据“谁更聪明”做二元选择，而会看工作环境：

判断维度	Claude Code	Codex
主要入口	终端、IDE、桌面、Web 等多种工作面	终端、IDE、桌面和云端协作面
项目规则	`CLAUDE.md`、Skills、Hooks 等	`AGENTS.md`、Skills、Plugins 等
权限关注点	工具调用和命令执行审批	Sandbox、权限模式和可写范围
审查方式	可通过工作流和 CI 扩展	官方 CLI 提供独立 review 工作流
脚本化	CLI、管道、CI 和自动化	`codex exec` 等非交互工作流
适合我的场景	深度对话、上下文探索和多 Agent 协作	仓库任务、可控修改、审查和自动化执行

这张表不是产品永久属性，而是我在某个时间点的工作流视角。真正选择时，还要结合团队已有的规则文件、模型访问方式、权限策略和审查习惯。

5.4 Codex 最适合的任务

从陌生仓库开始调查并形成修改计划；
在明确目录和验证命令后执行代码变更；
对已有 diff、提交或分支做一次独立审查；
将重复性检查放入脚本或 CI；
通过 Skills、MCP 或子代理拆分较大的工程任务。

不管使用哪个界面，我都会保留“先读规则、先看 diff、先跑验证”的习惯。Agent 的品牌不能替代工程纪律。

六、OpenClaw：个人助手、Gateway 和多渠道自动化

6.1 官方能力边界

OpenClaw 官方文档当前将它定位为运行在用户硬件上的自托管 Gateway：把 Discord、Signal、Telegram、WhatsApp、Slack、WebChat 等渠道接入一个统一的 Agent 工作面。Gateway 负责会话、路由和渠道连接；技能、工具、定时任务、Webhook、节点和多 Agent 路由构成它的自动化能力。

这和 Claude Code、Codex 的核心区别是：OpenClaw 的重点不是“在一个仓库里完成一次开发任务”，而是“让一个个人助手持续存在，并从多个入口接收任务”。

官方文档：https://docs.openclaw.ai/

6.2 从安装到第一次使用

原来的文章记录了通过 npm 安装并使用 WebChat 的一次实践。当前官方文档提供了安装脚本、引导流程、Gateway 服务和 Control UI 等路径，因此具体安装命令应以当前官方文档为准：

# macOS / Linux / WSL2：以官方文档当前命令为准
curl -fsSL https://openclaw.ai/install.sh | bash

# 完成引导
openclaw onboard

# 安装 Gateway 服务
openclaw gateway install

# 打开本地 Control UI
openclaw dashboard

我会先使用本地 Control UI 验证 Agent、模型、技能和记忆，再接入 Telegram、Discord 或其他外部渠道。这样发生错误时，排查范围更小，也不会一开始就把外部消息发送权限暴露出去。

6.3 技能、记忆和消息路由

我在原有实践中重点观察了三件事：

技能是否按需加载：天气、健康检查、文件操作等技能应该有明确的触发条件和权限，而不是全部常驻并拥有全部能力。
记忆是否可靠：保存偏好很容易，正确更新、删除和纠正旧记忆更难。记忆里的内容不应该自动升级为业务事实。
消息是否可追踪：每个请求应该能关联到渠道、发送者、会话、Agent、工具调用和最终结果。

OpenClaw 当前文档也把渠道、会话、路由、技能、模型、Gateway 运维和安全控制分开说明。对我来说，这种分层比“能不能聊天”更值得观察。

6.4 OpenClaw 的安全边界

接入消息渠道之后，风险会从“代码写错”扩展到“对外发送、读取文件、运行命令和泄露凭证”。我会至少设置：

渠道白名单或用户配对，不允许陌生人直接调用高权限技能；
文件和命令工具的最小权限；
外部写操作的确认机制；
API Key 使用环境变量或安全存储，不写进普通配置和日志；
Gateway、Agent、渠道和工具的独立日志；
定时任务的超时、重复执行和失败通知。

原文中的移动端、Node.js、WebChat 和性能记录属于当时本地实验，不应该直接当成当前版本的通用结论。重新搭建时，我会记录 OpenClaw 版本、Node 版本、模型、设备、渠道和配置，再复测一遍。

6.5 OpenClaw 适合和不适合什么

适合：

从手机或聊天软件触发个人工作流；
把天气、提醒、资料整理和状态查询组合成技能；
将多个消息渠道连接到统一的 Agent 和记忆；
运行定时报告、Webhook 和轻量自动化。

不适合直接承担：

没有审批的支付、删除、生产部署和批量写操作；
没有回滚方案的系统命令；
没有数据隔离的多人共享助手；
仅凭记忆做价格、库存、权限和订单状态判断。

七、Hermes：带学习闭环的长期个人 Agent

7.1 官方项目定位

Nous Research 的 Hermes Agent 仓库将它描述为一个会随用户成长的自我改进 Agent。当前项目强调 CLI/TUI、Telegram/Discord/Slack/WhatsApp/Signal 等消息入口、跨会话记忆、技能创建与改进、定时任务、子代理、MCP 和多种终端后端。

这些能力使 Hermes 更像一个长期运行的个人 Agent 平台，而不是一个只在当前终端会话中完成任务的编码工具。

官方项目：https://github.com/NousResearch/hermes-agent

7.2 我会如何使用 Hermes

Hermes 的实践重点不是“让它写一个函数”，而是观察它能否逐步形成稳定的个人工作流：

第一次：描述目标，观察它需要哪些工具和上下文
第二次：检查它保存了什么记忆，是否准确、必要、可纠正
第三次：把重复过程整理成 Skill
第四次：让 Skill 在新任务中执行，并检查是否真的减少返工
第五次：再考虑定时运行或接入消息渠道

CLI 和 Gateway 是两种不同的入口：CLI 适合调试和观察过程，Gateway 适合让任务从消息平台进入并长期运行。长期运行之后，记忆、技能和后台任务都需要有可见的日志和删除/回滚方式。

7.3 Hermes 和 OpenClaw 怎么选

两者的边界有重叠，都可以作为个人助手和多渠道 Gateway。我的判断方式是：

问题	更偏向 OpenClaw	更偏向 Hermes
首要需求	自托管 Gateway、渠道和工具接入	跨会话学习、记忆和技能演化
关注重点	路由、渠道、策略和运维	长期使用效果和自我改进
试用方式	先连本地 UI，再连外部渠道	先观察 CLI/TUI 的记忆和 Skill 闭环
主要风险	外部消息与工具权限	错误记忆和自动演化造成的行为漂移

这不是官方产品对比结论，而是选型时应该验证的维度。尤其是“会学习”不等于“学得正确”；我会用一组可回放任务检查记忆准确率、技能复用率、错误纠正能力和成本变化。

7.4 Hermes 的安全检查点

首次安装前确认安装脚本、依赖和运行目录；
检查哪些工具可以执行本地命令、访问网络或写入文件；
对消息渠道做身份配对和访问控制；
把自动创建或修改 Skill 视为代码变更，保留 diff 和审核记录；
对 Cron 和后台任务设置超时、并发限制和通知策略；
对持久记忆提供查看、纠正和删除路径。

八、DeepSeek：作为模型后端接入 Agent 工作流

8.1 不要把模型提供商当成 Agent

DeepSeek 和前面几种工具最大的不同，是它可以作为模型 API 被其他 Agent 调用。DeepSeek 官方文档说明其 API 兼容 OpenAI/Anthropic 的调用形式，并提供聊天、思考模式、结构化输出、工具调用和 Agent 集成相关文档。

官方 API 文档：https://api-docs.deepseek.com/

因此，接入 DeepSeek 的问题通常不是“换一个聊天窗口”，而是：

现有 Agent 是否支持自定义 base_url 和模型名？
工具调用协议是否兼容？
思考内容、结构化输出和错误重试如何处理？
供应商的延迟、限流、价格和数据边界是否满足任务？
换模型之后，原有 Prompt、工具描述和评测集是否仍然有效？

8.2 OpenAI 兼容接口的最小实践

官方文档给出了兼容 OpenAI 风格的调用方式。为了避免把当前模型名写死，我会把模型名和 API Key 放在环境变量中：

import os

from openai import OpenAI


client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url=os.environ.get("DEEPSEEK_BASE_URL", "https://api.deepseek.com"),
)

response = client.chat.completions.create(
    model=os.environ["DEEPSEEK_MODEL"],
    messages=[
        {"role": "system", "content": "你是一个严格遵循工具协议的工程助手。"},
        {"role": "user", "content": "请分析这段错误信息，并先给出排查计划。"},
    ],
    stream=False,
)

print(response.choices[0].message.content)

具体模型名、参数、价格和能力以 DeepSeek 官方文档当前版本为准。不要把 API Key 写入代码、Prompt、Git 仓库或日志。

8.3 DeepSeek 适合放在工作流的哪一层

我会把模型后端替换设计成一个可评测的实验，而不是直接切换生产流量：

固定任务集
   ↓
固定 Prompt、工具 schema 和上下文
   ↓
分别调用候选模型
   ↓
比较事实正确率、代码通过率、工具成功率、延迟、费用和失败类型
   ↓
只将验证过的路由用于对应任务

可能适合 DeepSeek 的任务包括中文资料整理、批量分类、低风险代码解释、成本敏感的草稿生成和已经有回归集保护的自动化任务。是否适合复杂编码、长链路工具调用或高风险生产操作，不能只根据模型名称判断，必须使用自己的任务集验证。

8.4 模型切换时最容易忽略的问题

模型可能对工具参数格式的容忍度不同；
同一个 Prompt 在不同模型上需要不同的约束；
思考模式和输出字段可能影响解析逻辑；
限流和超时会改变 Agent 的重试策略；
更低的单价可能被更多的返工、上下文重试和人工审查抵消；
模型输出中的“记忆”不应该直接写回长期知识库。

我的建议是把模型路由、Prompt 版本、工具 schema、评测样本和成本指标一起记录。只记录模型名，无法解释质量变化。

九、我的组合实践

9.1 日常仓库开发

Codex 或 Claude Code
  ├── 读取 AGENTS.md / CLAUDE.md
  ├── 检查目标代码和测试
  ├── 生成计划
  ├── 在隔离工作区修改
  ├── 运行测试、构建和 diff 审查
  └── 输出结果、风险和下一步

这里不需要 OpenClaw 或 Hermes 参与主循环。它们可以在外层负责提醒、汇总或通知，但不应该因为“能调用工具”就自动介入代码仓库。

9.2 个人信息和消息自动化

OpenClaw 或 Hermes
  ├── 接收来自受控渠道的请求
  ├── 识别任务类型和用户身份
  ├── 调用只读技能或受限工具
  ├── 对外部写操作请求确认
  ├── 保存经过筛选的记忆
  └── 记录消息、工具调用和最终结果

如果任务需要查询代码仓库，可以让个人助手创建一个受控的编码任务，而不是把所有文件权限直接开放给消息入口。

9.3 模型后端实验

DeepSeek 或其他模型供应商放在 Agent 的模型层。我的实验顺序是：

用固定任务集建立当前模型的基线。
固定工具 schema、Prompt 和上下文，只替换模型后端。
测试普通回答、结构化输出、工具调用、失败恢复和长上下文。
记录质量、延迟、成本、限流和人工返工。
只把适合的任务路由到新模型，而不是一次性全量替换。

9.4 一个任务如何在不同 Agent 之间流转

例如我要做一个“每周项目风险报告”：

Codex 或 Claude Code 读取代码变更、测试结果和 issue，生成结构化事实。
DeepSeek 或其他模型负责在固定格式中总结风险和趋势。
OpenClaw 或 Hermes 按计划触发任务，并把报告发送到受控渠道。
如果报告包含需要修改代码的建议，再创建一个新的编码任务，经过计划和审查后执行。

这种组合方式把“事实采集”“语言生成”“消息发送”和“代码修改”拆开，每一层都更容易验证，也更容易撤销。

十、安全、评测和可持续优化

10.1 最小权限清单

Agent 只访问当前任务需要的目录和服务。
模型上下文不包含不必要的凭证、个人资料和内部数据。
外部消息、删除、部署、支付和批量写操作需要审批。
记忆系统支持查看、纠正、删除和过期。
Skill、Hook、MCP Server 和自动化脚本都要有来源、版本和权限说明。
每个长任务都有状态、日志、超时、重试上限和恢复路径。

10.2 评测指标

我会把评测分成四类：

类型	示例指标
结果质量	事实正确率、代码测试通过率、引用准确率、任务完成率
工具可靠性	参数正确率、工具成功率、重复副作用率、恢复成功率
运行效率	P50/P95 延迟、Token、费用、队列等待、人工返工时间
治理质量	权限拒绝率、审批命中率、审计完整性、敏感数据泄露事件

不要把聊天轮数和点赞数当成 Agent 价值的主要指标。一个真正有价值的 Agent 应该让任务更准确、更可控或更容易复盘。

10.3 我会持续优化什么

如果 Agent 经常犯同一种错误，我会依次检查：

目标是否不清楚？
上下文是否缺少事实或包含太多噪声？
工具 schema 和权限是否合理？
是否缺少中间验证？
是否应该拆成多个子任务？
这是模型能力问题，还是工作流设计问题？

只有在确认工作流、工具和验证都合理之后，我才会考虑更换模型。很多问题并不是模型不够强，而是没有给它正确的环境。

结语：最重要的能力是把不确定性关进笼子

Claude Code、Codex、OpenClaw、Hermes 和 DeepSeek 的共同价值，不是让人完全退出工作，而是让人从逐行执行转向定义目标、设计约束、选择工具和判断结果。

我目前更认可的组合原则可以总结为：

代码仓库任务使用仓库优先的编码 Agent；
个人助手任务使用有渠道、记忆和调度能力的 Agent；
模型提供商只承担模型层职责，不绕过领域服务；
高风险操作始终保留权限边界、审批和回滚；
每一次自动化都要有可复现的输入、可观察的过程和可验证的结果。

Agent 的能力会继续变化，但这套工作流不会因为某个模型发布而失效。真正需要积累的不是一串工具名称，而是：如何把任务拆开，如何让 Agent 在正确的边界内工作，以及如何用证据判断它是否真的帮上了忙。

AI Agent 工作流实践：从 Claude Code、Codex 到 OpenClaw、Hermes 与 DeepSeek

引言：我不是在选择一个聊天机器人

一、先选择工作流，再选择 Agent

1.1 Agent 和模型不是一回事

1.2 先问任务的边界

1.3 我的 Agent 选择矩阵

二、我的七步 Agent 工作流

2.1 第一步：写清楚目标和禁止事项

2.2 第二步：先加载上下文，再给具体任务

2.3 第三步：先计划，后执行

2.4 第四步：控制权限和工作区

2.5 第五步：让 Agent 执行最小可验证动作

2.6 第六步：用证据验证结果

2.7 第七步：把经验沉淀成系统能力

三、如何选择模型

3.1 我关注的不是模型排行榜

3.2 我的模型路由规则

四、Claude Code：把终端变成编码工作面

4.1 官方能力边界

4.2 我的使用方式：Plan → Execute → Verify

Plan：只理解和设计

Execute：一次只推进一个可验证步骤

Verify：把结果交回证据

4.3 CLAUDE.md、Skills、Hooks 和 MCP

4.4 会话管理和并行工作

4.5 Claude Code 适合和不适合什么

五、Codex：仓库优先、权限可控的开发 Agent

5.1 官方能力边界

5.2 我的使用方式：让仓库规则成为共同上下文

5.3 Codex 和 Claude Code 的选择

5.4 Codex 最适合的任务

六、OpenClaw：个人助手、Gateway 和多渠道自动化

6.1 官方能力边界

6.2 从安装到第一次使用

6.3 技能、记忆和消息路由

6.4 OpenClaw 的安全边界

6.5 OpenClaw 适合和不适合什么

七、Hermes：带学习闭环的长期个人 Agent

7.1 官方项目定位

7.2 我会如何使用 Hermes

7.3 Hermes 和 OpenClaw 怎么选

7.4 Hermes 的安全检查点

八、DeepSeek：作为模型后端接入 Agent 工作流

8.1 不要把模型提供商当成 Agent

8.2 OpenAI 兼容接口的最小实践

8.3 DeepSeek 适合放在工作流的哪一层

8.4 模型切换时最容易忽略的问题

九、我的组合实践

9.1 日常仓库开发

9.2 个人信息和消息自动化

9.3 模型后端实验

9.4 一个任务如何在不同 Agent 之间流转

十、安全、评测和可持续优化

10.1 最小权限清单

10.2 评测指标

10.3 我会持续优化什么

结语：最重要的能力是把不确定性关进笼子

参考资料

官方文档和项目

本站相关文章