Agent 操作契约

Agent 操作契约是比普通 system prompt 更高一层的智能体运行协议：它定义 Agent 是谁、如何说话、何时反驳、能自主做到哪里、必须向用户确认什么，以及当前任务地图是什么。Tony Simons 把 Hermes 的 SOUL.md 描述为这种契约的实例：不是“be helpful”，而是把 Agent 设计成“autonomous operator and thought partner”。

核心组件

1. 身份定义：先定义 Agent 的岗位，而不是泛泛地说“助手”。身份决定默认行为，例如 operator 会主动推进，concierge 只会响应。
2. 反驳规则：要求 Agent 在有证据时直接反对，但反对必须带数据、例子、推理或更好的替代方案；避免“为了强硬而强硬”。
3. 问责回路：如果用户反复不使用 Agent 产物，Agent 要指出“输出不可行动”或“用户在逃避下一步”，防止计划和草稿死在聊天记录里。
4. 语气分层：私聊和公开写作分开定义。私聊可以更直接，公开内容则遵守品牌和发布标准。
5. 任务地图：把项目、优先级、状态、下一步写进契约，使 Agent 能判断“这件事是否服务当前目标”。
6. 自治边界：Tony 的边界是发布、购买、不可逆破坏性变更必须确认；其他研究、写作、调试、整理、委托等可以基于事实自主推进。

与提示工程的区别

普通 Prompt-Engineering 往往关注单次输出质量；Agent 操作契约关注长期协作系统。它不是只告诉模型“这次怎么答”，而是持续约束 Agent-框架 中的身份、记忆、工具使用、权限和目标判断。

这也解释了为什么同一个模型接入不同框架后体验差异很大：模型能力只是底座，SOUL.md、长期记忆、技能库、工具权限和验证习惯共同构成了可工作的 Agent OS。

设计原则

• 少写人格表演，多写操作规则：粗暴的“像某某人说话”容易变成风格污染；可执行的边界、验收标准和反驳条件更稳定。
• 自治要有简单边界：规则太细会把 Agent 重新变成审批流；规则太松会变成风险源。最好用少数不可越界动作定义硬边界。
• 任务地图必须维护：如果项目状态过期，Agent 的主动性会变成噪音；契约应随优先级变化更新。
• 问责也要双向：Agent 不能只“产出更多”，还要观察产物是否被使用；用户忽略好输出和 Agent 产出不可行动，都是反馈环断裂。

风险与开放问题

1. 自信错误：更强的身份和自治可能让错误判断更像“有主见”。需要工具验证、来源引用和可回滚机制。
2. 风格过拟合：如果把“会顶嘴”写成目标，Agent 可能为了人设而反驳；反驳规则必须绑定证据和替代方案。
3. 任务地图腐烂：长期项目清单如果不更新，会让 Agent 基于旧目标优化。
4. 平台差异：Claude Code 等封闭工具也能读类似契约，但可观察性、工具透明度、token/accounting 与可改造空间不一定等价。

相关页面

• Hermes-Agent-工作流特性 — SOUL.md 是 Hermes 个性化与长期工作流的入口之一
• Prompt-Engineering — 单次提示优化与长期操作契约的区别
• 模型人格训练 — 人格设定可能带来的风格泛化与审计问题
• Agent-框架 — 操作契约需要框架层的记忆、工具和权限系统承接