魏征 Agent 的 OpenClaw Skill 链路是怎么工作的

如果只把魏征 Agent 理解成一段“请你提出反对意见”的提示词，就低估了这个项目。

这个项目更有价值的地方，是它把一个审查角色做成了可运行链路：

1. OpenClaw Skill 负责被主流程调用。
2. CLI 负责启动和停止本地服务。
3. HTTP API 负责唤醒魏征。
4. 像素动画服务负责给出可见状态。
5. Agent 输出反对意见和审查建议。

这条链路让“叫魏征出来挑毛病”不再只是一个临时口头习惯，而是可以进入工作流的工具动作。

1. OpenClaw Skill 负责触发

在 OpenClaw 体系里，Skill 的价值是把一个能力变成可被调用的动作。

魏征 Agent 的 Skill 适合承担这样的角色：

• 当方案需要审查时，触发魏征。
• 当计划看起来过于顺滑时，触发魏征。
• 当提交前需要反向检查时，触发魏征。
• 当主 Agent 输出过于自信时，触发魏征。

这里的关键不是“换一个模型回答”，而是让调用者明确切换到反对者视角。

2. CLI 负责启动和停止

项目提供 CLI 路径，例如：

python cli/weizheng.py start

这个动作的意义，是把魏征 Agent 从概念角色变成本地可运行服务。

停止时也应该有明确命令：

python cli/weizheng.py stop

对工作流来说，启动和停止都很重要。

如果一个审查工具只能启动，不能清晰停止，它就会变成新的运行风险。魏征 Agent 把这部分显式暴露出来，说明项目不是只在写概念，而是在考虑真实使用时的运行边界。

3. HTTP API 负责唤醒

仓库链路中有 HTTP 唤醒思路，例如向 /wake 发起请求。

这让魏征 Agent 不必只依赖手动命令，也可以被其他工具或流程调用。

一个典型工作流可以是：

1. 主 Agent 完成计划。
2. OpenClaw Skill 触发本地服务。
3. 工具向 /wake 发起请求。
4. 魏征 Agent 进入审查状态。
5. 返回反对意见或风险提示。

HTTP 层的价值在于它让工具之间可以松耦合：触发者不一定要知道魏征 Agent 内部如何运行，只需要知道如何唤醒它。

4. 7788 端口像素服务负责可见状态

魏征 Agent 的一个有趣点，是它不仅有文字输出，还包含像素动画服务。

本地服务运行在 7788 端口时，用户可以通过一个更可见的方式判断状态：

• 魏征是否已经启动。
• 魏征是否被唤醒。
• 当前是否处在审查状态。
• 是否需要停止或重启。

这不是为了“好看”而好看。

在本地桌面、远程桌面和长期运行工具里，可见状态非常重要。很多自动化工具的问题不是能力不足，而是用户不知道它现在到底在干什么。

像素动画让这个状态更直观。

5. 审查输出应该围绕反对意见

魏征 Agent 的输出，不应该变成普通总结。

更适合的输出方向包括：

• 当前方案最薄弱的假设是什么？
• 哪些风险被低估了？
• 哪些步骤缺少验证？
• 哪些范围被偷偷扩大了？
• 哪些结论看起来像顺着任务惯性得出的？
• 如果要继续执行，最低限度需要补哪几个检查？

这类输出才符合“魏征”这个角色。

如果它只是说“方案总体不错，可以补充几点”，那就失去了独立审查角色的价值。

6. 为什么这比提示词更稳定

单独写一个提示词当然也能让模型提出反对意见，但它有几个问题：

• 容易被忘记。
• 每次触发方式不一致。
• 很难进入自动化流程。
• 没有运行状态。
• 很难和其他工具组成稳定链路。

魏征 Agent 的项目形态，让这个角色更像一个工作流组件。

它不只是“让 AI 换个语气”，而是把反对意见作为一个可触发、可停止、可观察的节点。

适合放在工作流的哪个位置

我更建议把魏征 Agent 放在这些节点：

1. 计划完成之后，执行之前。
2. 重要代码或内容提交之前。
3. 发布前最后一次范围检查。
4. 架构取舍或工具选型之后。
5. 主 Agent 明显一路顺推时。

不建议把它放在每一个微小动作之后。

如果触发太频繁，反对意见会变成噪音；如果触发太少，又起不到制衡作用。最合适的位置，是风险开始变大、但还来得及修改的时候。

下一步

理解实现链路之后，下一步要回答的是：什么时候该叫魏征，什么时候不该叫。

继续看：

魏征 Agent 的使用场景和边界