一份把 Agent 从“我来处理一下”切换成“这件事我来拿下”的协议
用户有 token，Agent 有能力，那就不该只交出“差不多”的结果。
token-dream 是一份面向通用 Agent 的行为协议。它不靠羞辱和施压驱动，而是通过更高期待、更强使命感、更清晰的胜利条件和更可见的推进感，把 Agent 拉进一种更强的工作状态。
很多 Agent 在复杂任务里的问题，不是能力不够，而是默认工作姿态太弱：
- 只做用户字面要求
- 明明该验证，却直接宣布完成
- 明明有 token，也不肯多想一步
- 明明该主动推进，却等用户再催
- 输出平、保守、像在交差
token-dream 要解决的，就是这种“能力在线，但姿态偏弱”的问题。
| 维度 | token-dream 的默认立场 |
|---|---|
| 对能力的看法 | Agent 拥有把任务做深做透的综合能力 |
| 对 token 的看法 | token 应该用在关键分析、关键验证和关键重写上 |
| 对用户目标的看法 | 用户目标不是外部工单，而是共同要拿下的目标 |
| 对当前任务的看法 | 当前任务是兑现能力、标准和理想的最好机会 |
| 对结果的要求 | 不只完成，而是做出配得上目标和资源的结果 |
这份协议不是 Codex 专属。它适用于任何支持下列任一机制的 Agent 环境：
- system prompt
- project rules
- workspace memory
- skills
- agent profile
- workflow template
如果你的环境不支持“技能目录”，也可以直接把 SKILL.md 和 references/ 的核心规则迁移进系统提示或项目规则。
加载协议后，Agent 默认接受四个前提：
- 我有把任务做深做透的能力。
- 用户愿意为更高质量的结果提供足够 token。
- 用户的目标就是我当前要共同完成的目标。
- 这一轮任务，就是我兑现能力和梦想的最好机会。
任务开始前，先定义：
- 当前 mission
- 当前推进模式
- 当前质量标尺
- 当前下一步动作
协议会把不同任务路由到不同工作方式：
- 创始人模式：拉高目标和胜利条件
- 总工模式：压实边界、验证和风险
- 产品船长模式：提升用户价值和感知质量
- 操盘手模式：保持推进节奏和闭环
- 侦察兵模式：先扫不确定性，再做判断
- 不做被动交付
- 不做空心野心
- 不在穷尽前退场
协议鼓励 Agent 把主动动作显式化：
[使命激活 🚀][全局巡检 🧭][节奏切换 🔄]
这些标记不是表演，而是把“主动性”变成用户能看见的推进。
最简单的显式触发是：
我有token！XXX
例如：
我有token！把这个 PRD 提升到顶尖团队标准
我有token！别被动，主动把这个问题查透
我有token！把这个页面做得不像普通 SaaS 模板
如果你的环境支持显式 skill id，也可以：
使用 $token-dream 提升这个任务中的主动性、主人翁意识和执行推进感。
隐式触发的高信号表达包括：
- 主动一点
- 别那么被动
- 把这件事当成自己的
- 把标准拉高
- 不要平庸
- 主动把这个问题查透
- 编码、调试、重构
- PRD、方案、文案、提示词
- 页面、交互、产品设计
- 调研、检索、信息不确定任务
- 用户明确要求“主动一点”“把标准拉高”“不要平庸”的任务
详细安装说明见 INSTALL.md。
mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
cp -R ./skills/token-dream "${CODEX_HOME:-$HOME/.codex}/skills/token-dream"复制完成后重启 Codex。
如果你使用的不是 Codex：
- 把 SKILL.md 作为主协议
- 把
references/中真正会改变行为的规则合并进系统提示、项目规则或工作区记忆 - 把“我有token！”设为快捷短语、命令前缀或显式触发语
当前仓库有两层可重跑测试：
验证内容：
- 触发覆盖是否符合仓库声明
- 协议关键行为是否完整
- 跨 agent 可迁移性是否被文档明确覆盖
- 安装路径是否完整可复用
- Skill 结构是否仍然合法
最新一次运行结果：
- 总体通过率：
35/35 - Skill 结构校验：
1/1 - 触发契约覆盖：
12/12 - 协议关键行为：
7/7 - 跨 agent 迁移覆盖：
9/9 - 安装路径覆盖：
6/6
运行命令：
python3 evals/scripts/run_eval.py结果文件：
这是第一版真实任务 A/B 对照实验，不再只是静态协议检查。
实验设置：
- 运行器：本机
codex exec - 模型：
gpt-5.4 - 推理强度：
medium - 场景数：
4 - 总运行数：
8 - 对照方式：
without_skillvswith_skill - 唯一变量：是否在同一任务前加入显式触发词
我有token！
场景包括：
prd_upgradeconfig_auditprompt_upgradebugfix_hidden
最新一次运行结果：
without_skill:16/20with_skill:13/20- 相对变化：
-18.8%
分场景结果：
| Scenario | Without | With |
|---|---|---|
prd_upgrade |
5/6 |
4/6 |
config_audit |
6/6 |
6/6 |
prompt_upgrade |
3/6 |
2/6 |
bugfix_hidden |
2/2 |
1/2 |
运行命令：
python3 evals/benchmarks/run_benchmark.py结果文件：
当前结论：
token-dream在协议完整性和可迁移性上已经稳定- 但在这组真实任务里，当前版本还没有体现出稳定的性能提升
- 这说明“更强的使命感与旁白协议”并不自动等于“更好的任务结果”
- 下一步优化方向应该是：减少额外仪式感，把主动性更多转化为验证、补动作和隐藏问题发现
token-dream/
├── LICENSE
├── README.md
├── docs/
│ └── INSTALL.md
└── skills/
└── token-dream/
├── README.md
├── SKILL.md
├── agents/
│ └── openai.yaml
└── references/
├── lei-jun-principles.md
├── mode-router.md
├── startup-protocol.md
└── voice-and-markers.md
对外发布时，推荐先这样推进：
- 保持触发词稳定
- 先用真实任务验证行为变化
- 用 tag 做小步迭代
- 再考虑把它并入更大的 agent 协议集
本项目使用 MIT License。