解密Hermes的goal指令：如何让AI理解你的真实意图

解密Hermes的goal指令：如何让AI理解你的真实意图
本文属于「Hermes Agent自进化智能体深度解析」系列 | 模块二 · 第1篇

你真的会让AI做事吗？
“帮我写一个API。”

这是一句再普通不过的需求描述。但如果把这个需求交给一个AI Agent，会发生什么？

它可能会生成一个没有任何业务逻辑的空壳API，也可能会基于自己的理解构建一个完全偏离你预期的实现。不是AI能力不够，而是你给的指令太模糊了。

这就像你走进一家餐厅，对服务员说"给我来点吃的"——服务员可能端来一碗面，也可能端来一份牛排，取决于他们怎么理解你的"吃"。

在传统的AI使用模式下，你需要在多轮对话中不断补充细节，逐步逼近你真正想要的东西。但在Hermes Agent的世界里，有一种更高效的方式——/goal指令。

/goal：把模糊意图变成执行契约
什么是Execution Primitive（执行原语）？
在编程语言中，“原语”（Primitive）是指最基本的操作单元——一切复杂的逻辑都可以由这些基本单元组合而成。/goal就是Hermes Agent体系中的执行原语。

当你发出一个/goal指令时，你不是在"描述需求"，而是在"签订一份执行契约"。

一份完整的/goal契约包含以下要素：

/goal: 构建用户匹配API
Done State（完成状态）:

• API能接收用户profile并返回匹配结果列表
• 支持按兴趣、活跃度、地理位置等维度匹配
• 响应时间 < 200ms（P95）
• 单元测试覆盖率 > 80%
  Boundary（边界）:
• 仅实现后端API，不涉及前端
• 使用现有的PostgreSQL数据库
• 不引入新的外部依赖
  Constraint（约束）:
• 必须兼容现有的认证中间件
• 遵循RESTful API设计规范
• 所有敏感数据必须脱敏处理
  Verification（验证方式）:
• 自动化测试全部通过
• API文档自动生成
• 性能基准测试报告
  看到了吗？这不是一句"帮我做个API"，而是一份精确的执行说明书。

Kanban-Based Execution：从目标到看板
一个Goal的生命周期
当/goal指令被发出后，Hermes不会直接开始写代码。它首先将Goal拆解为一系列看板卡片（Kanban Cards），每一张卡片代表执行流程中的一个阶段：

┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐
│ Spec │→ │ Build │→ │ Review │→ │ Fix │→ │ Verify │→ │ Summary │
│ 规格定义 │ │ 代码实现 │ │ 质量审查 │ │ 问题修复 │ │ 验证确认 │ │ 总结归档 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └──────────┘
Spec Card（规格定义）

Hermes首先根据Goal和Done State生成详细的技术规格文档：

数据模型设计（Schema）
API接口定义（Endpoints）
业务逻辑描述（Logic Flow）
测试策略规划（Test Plan）
这张卡片完成后，会经过人机共同确认，确保理解没有偏差。

Build Card（代码实现）

Spec确认后，进入构建阶段。这个阶段由Builder角色（如Codex）负责：

按照Spec逐项实现功能
编写配套的单元测试
生成必要的文档和注释
Review Card（质量审查）

构建完成后，由Reviewer角色（如Claude Code）进行全面审查：

代码质量评估
安全漏洞扫描
架构一致性检查
性能瓶颈排查
Fix Card（问题修复）

Review中发现的问题会被记录为Fix卡片：

优先级排序（Critical / High / Medium / Low）
每个问题的修复方案
修复后的回归验证
Verify Card（验证确认）

所有修复完成后，进入最终验证：

全量测试执行
构建状态检查
Git状态验证
文件系统差异检查
运行时日志分析
Summary Card（总结归档）

最后，生成完整的证据报告并归档：

Goal描述和Done State
参与的Workers列表
变更文件清单
测试执行结果
Review审查结论
风险评估
发布决策
为什么用看板而不是线性流水线？
看板模型的灵活性远超线性流水线。在实际执行中：

Review发现Critical问题 → Build卡片可以回到"进行中"状态
Verify阶段发现新问题 → 可以创建新的Fix卡片而不影响已完成的工作
多个独立的子目标 → 可以并行推进各自的看板流程
这种灵活性确保了执行过程既能保持秩序，又不会因为某个环节的问题而阻塞整个流程。

Done State：AI自主执行的"停车线"
Done State是整个/goal体系中最关键的概念。它定义了“什么才算做完”的精确标准。

没有Done State的Goal就像没有终点的旅行——AI可能会永远"优化"下去，也可能在完成80%时就停下来。

Done State需要满足三个特性：

可验证性（Verifiable）：每个条件都可以通过自动化手段客观判定，不依赖人的主观判断。

✓ 单元测试覆盖率 > 80% → 运行测试工具即可得出精确数值
✗ 代码质量好 → 什么是"好"？谁来定义？
完备性（Complete）：所有关键维度都被覆盖，不存在遗漏。

✓ 覆盖功能完整性、性能、安全性、可测试性
✗ 只写了"功能正常"，没提性能和安全
无歧义性（Unambiguous）：每个条件的表述只有一种理解方式。

✓ 响应时间 < 200ms（P95），测试数据集1000条
✗ 响应要快
当AI完成所有Done State的条件时，它会生成一份证据报告（Evidence Report），逐项展示每个条件是如何被满足的。人只需要审核这份报告，而不是逐行检查代码。

从"指挥AI"到"管理AI"
理解了/goal和Kanban-Based Execution后，你会发现一个深刻的角色转变：

传统模式下，你是AI的指挥官——你告诉它每一步做什么，每一步做完你检查，然后告诉它下一步。你的时间和精力被完全绑定在执行过程中。

/goal模式下，你是AI的项目经理——你定义目标和验收标准，AI自主执行，你只需要在关键节点审核证据报告。你的精力被释放出来，去思考更高层级的问题。

这不是说人变得不重要了。恰恰相反，定义一个好的Done State需要比写代码更高层级的思维能力——你需要理解业务目标、技术约束、质量标准和风险边界。

从指挥AI到管理AI，这是AI原生时代人类最核心的能力升级。

延伸阅读与交流
本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

主题：AI原生Hermes自进化智能体系统
时间：2026年7月4-5日（周末）
形式：线上直播
内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层
分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。

技术交流

联系人：赵老师 13311271064