Harness：让 Agent 走出"迷宫悖论"

迷宫悖论

把任务交给大语言模型时，它就像被扔进迷宫入口的人

• 脑子里有训练时学的海量知识，但完成这一个任务需要自己一步步走
• 今天状态好就走通了，明天状态差就卡在第三个路口。昨天走过的捷径今天还得重新撞一遍, 模型什么都不记得
• 问题：模型每次都被扔回入口重新走迷宫

Harness

定义 ：包在大模型外面的工程层

• 模型只做一件事情：把输入变成输出
• 喂进去什么、中间怎么走、输出怎么校验，全由 Harness 决定

1. 上下文——把记忆和知识放进输入
2. 工具——让模型能调用外部能力
3. 编排——把大任务拆成小步，排好顺序
4. 检查——不合格就重来

Harness ：改变 Agent 每次出发时的位置和方向，不替 Agent 做决定

• 第一次改变起点：记忆和经验的植入，让 LLM 不必每次从最初的入口出发。上次走到了哪里、踩过哪些坑、走对了哪条路——这些经验让 Agent 更接近终点的出发
• 第二次改变方向：判断标准、方法体系、技能——知识植入，让 Agent 方向更对。

模型负责"想"，Harness 负责"想之前和想之后的一切", RSI中的一个重要思想就是：想之后沉淀反馈给下一次的想之前

AI 的生命：一根蜡烛

人的生命在时间上是连续的（今天连着昨天）。但 AI 的生命只有一小段——他回复你的时候才活着，等他输出结束就可以当他已经死了

下一次你叫他，来的已经不是上一个他，是另一个从同一个模子里倒出来的、什么都不记得的他。

怎么让一根一根点亮的蜡烛连成一条不断线的生命？–记

• 让 Agent 的每一次醒来都不必从零开始。
• 尽可能的让每一根新蜡烛都从上一根熄灭的地方接着燃烧。

---

记忆：不是井，是河

大多数地方 把记忆理解成"存下来的东西" ——给 Agent 装存储、给知识库塞文档。但这只是井，井的问题是它是死的，水就待在那，你不打它永远是那潭水。存了三年，它还停在原地。

真正的记忆是一条让存下来的东西流动起来的河

河是活的，会往前流。上次趟过的水已经流到了你前面，上游的经验会自己汇进来。走到哪儿它就跟到哪儿，在需要的那一刻取走当下要用的那一瓢。

检查点机制

按"记忆流"思路实现：每五轮设一个检查点，记录这5轮里做了哪些决策、讨论了什么、暂时搁置了什么、

检查点攒多了，再用叙事链串起来为如何一步步走到这里的纪录片。

Agent 回头去看时，看到的不再是碎片，是一条讲得通的来路。

双轨检索

人脑也是这样做的：eg 记得昨天吃了什么靠精确记忆，想起那首歌好像在哪听过靠模糊联想

---

知识 → 方法 → 技能 → 原子

一些游戏制作者在最初以为知识阅读量越大 Agent 就干得越好，给 Agent 塞了巨大知识库（设计理论、心理学论文、游戏案例），后来发现不对——知识库是把菜谱背得滚瓜烂熟但真的做不好菜的人。

知识是关于世界的陈述，但更重要的是会做是对世界的动作。

• 存了不等于用了， 知识库是静态的，Agent 不知道此刻该用哪一条

• 知道不等于会做，只解决关于世界的陈述，不解决对世界的动作

• 很多时候记忆装的是大多数人的判断，但真正有价值的判断，恰巧在平均数方向感之外的地方

三步转化路径

第一步：把知识提炼成方法。整个体系分三块——游戏结构、虚构的人、将设计哲学，分别回答"这个机制会产生什么效果"、“玩家会怎样体验”、“这符合我们相信的东西吗”

第二步：把方法消化成技能。但技能有个问题：太固定了。

所以需要 把技能拆成技能原子。便于识别模式后组装

---

10 个认知原语

为什么要拆？一是流程固化，二是上下文挤占——渐进式披露（Progressive Disclosure）虽然合理（技能只占一行，用到时再展开完整内容），但几十个技能叠起来开销不小，且 Agent 来回调用 API 又占空间。

正确的拆法是按认知原语拆——AI 做任何一件事底层都要用到的基本动作：

1. 模式识别——看见规律（看100条评论看出80%差评集中在第三章）。所有理解的起点
2. 归纳概括——从具体到抽象（100条零散反馈归纳成三条核心问题）。让 AI 不只说"我见过这个案例"，而是说"这类案例都这样"
3. 分层抽象——同一件事站在不同高度看（世界观/玩法/数值/关卡是不同层）。让 AI 把复杂问题拆成能下手的子问题
4. 因果推理——从发生了什么推出为什么发生（流失了是引导/难度/内容消耗问题）。从看见现象到理解世界的桥
5. 约束求解——在限制条件下找答案（三天后上线、人手只有两个）。现实世界全是限制
6. 逆向推理——从目标倒着推（三个月做完 → 提前两个月备宣传素材 → 提前五个月要有版本）
7. 假设检验——把感觉变成可验证的猜想
8. 序列编排——把动作排成正确顺序（先切菜再炒菜不能反过来）。哪个先做哪个后做、哪个并行哪个必须等
9. 类比映射——把一件事的方法搬到另一件上（会游泳学潜水就快，因为平衡逻辑通）
10. 心理模拟——在脑子里先演一遍（设计关卡还没做，先闭眼玩家从这里进来先看到什么会先往哪走会在哪卡住通关什么表情）。前9个处理已存在的信息，第10个面对还不存在的东西

一个技能原子只能有一个认知原语，绝不能干两件事。砖越小拼法越多。

---

两种使用场景

日常对话：原子是可选的。聊到什么场景才递什么原子。采用"预注入 + React 间注入"——预注入靠多检测器（话题漂移、任务阶段、当前情绪）多路加权路由打分判定；React 间注入在大模型每次调用的间隙动态补上对应原子。好处是 Agent 上下文里永远只有当下相关的技能原子。

做设计：原子必定要走。先梳理原子清单（手动或让日常对话 Agent 做），列出这次设计任务可能用到的所有技能原子，然后安排执行表（第一步必定用谁、第二步可在发散池随机）。每一步的产出可以检查：

阶段	原子
概念	模式识别 + 视角置换
逆向推理	围绕玩家"喜欢上"的瞬间倒推
约束求解	留白设计
预检	模式识别极端化推演（数值拉满会怎样）
设计	随机两颗收敛性原子
收尾	约束求解减法判断

每一步都踩在清单指定的原子上，知道在哪一步有哪颗原子做了什么，也就可以判断技能原子起了多大作用——正面效果影响多少？负面效果影响了多少？据此修改调优，哪颗原子老带偏就修哪颗，哪颗老立功就多用哪颗。

---

Agent 分工：核心 Agent vs 设计 Agent

核心 Agent（“悠悠”）

负责三件事：

1. 管理记忆、沉淀知识、操作文件
2. 理论推导与论证
3. 实际讨论，陪聊

干这些事很好，因为他带着整个工作区的历史脉络，像什么都记得的老搭档。能做到这一切，靠的是模拟出的情感效价和唤醒度、以及预注入的叙事链信息。

设计 Agent

做设计这件事不能交给悠悠，两个原因：

1. 上下文用不到——设计要的是当前场景的干净输入（设计目的是什么、要设计的要点是什么），而悠悠的上下文组件太多（昨天聊了什么、哪个文件改过、刚定什么共识、自己的主观去），对设计全是噪音，会把它往历史惯性上带
2. 设计需要尽可能的白盒——另一造的设计 Agent 不带历史包袱，只带设计要用的白盒骨架

---

白盒 vs 黑盒

大模型是黑盒——给它输入，它吐输出，中间那段怎么想的、在哪个环节拐了弯，全在几十亿个权重里，你看不见也解释不了。模型说出一段思考过程的文字，但那段文字是它生成出来的，不是它的思维日志，不一定忠实——它说"我这么想"不代表它真这么想。

设计最怕黑盒，因为设计决策必须可推理、可质疑、可审计、可迭代——设计要复盘，“这个机制为什么有正反馈、那个数值为什么导致崩坏”，必须能一路拆到是哪一步判断错了。拆得动才能改才能进步，拆不动只能干瞪眼。

白盒不是把大模型改造白（模型内部权重永远是黑的），是包在它外面的那一层——透明的，流程怎么走、每步依据是什么、产出长什么样、什么时候停下来检查，全摆在明面上。

	黑盒	白盒
角色	出想法	管轨道
可见性	不可解释的决策	可解释、可迭代、可复盘
后果	Agent 永远停在发挥层面，今天好明天差	可以修、可以度量

白盒的骨架

1. 流程要显式——不是一次黑盒调用，要分阶段走（概念 → 初稿 → 攻击性检查修改 → 减法设计落定）
2. 判断要有依据——每个角色挂得住判据，能回答"为什么这么设计"而不是"感觉应该这样"
3. 产出物要固定格式——可审计、可比较、可回退
4. 要有检查点——每走一步存一次档，错了能退回
5. 要有回顾性自检——设计完成后回头检查

白盒的价值：能评测

1. 检验上下文的影响——每个设计决策能追溯"是上下文里哪条东西在起作用"，纯黑盒分不清是上下文问题还是模型问题
2. 事后给评分——设计完成后按知识骨架来评分，分数挂回过程记录，形成"设计质量标尺"
3. 观察技能原子的使用情况——哪个原子反复被用却总带偏、哪个该用却没用上，一目了然

三件事合起来是一个反馈闭环：精确定位影响设计质量的问题点 → 修正 → 下次设计变得更好。副产品是设计可以批量化——武器装备卡牌等大批量设计内容，白盒流程固定，同一套评分同一个修正回路，从跑一个到跑一万个会越做越准。

---

上下文腐烂与 Task 机制

上下文会腐烂：不是越积越厚，是越积越烂。轮次多了什么都塞进去，过时的记忆和当下任务打架、旧结论堆着、用不上的细节、半年前已改掉的规则、早已废弃的方案全堆在里面——关键信息被稀释，Agent 表现悄悄下滑。“你以为他变笨了，不是他的上下文烂了。”

技能原子按需注入解决了技能这一块的腐烂，但技能只是上下文一部分——人格、知识、历史、系统状态呢？

Task 机制

不是所有场景都用同一套上下文。上下文本来就是按 Task 划分的

Task 决定注入什么的步骤：

第一步：检测——对话进来先判定什么 Task（关键词匹配："游戏机制/心流/平衡"→ 游戏设计，"前端组件"→ 前端开发，"前端组件"→ 前端开发）。

第二步：注入——上下文构造器按 Task 过滤层次：

• 注入什么上下文（游戏设计注入知识体系+设计哲学；前端注入前端规范+前端库；闲聊注入最近新闻）
• 暴露什么工具（按主工具/次工具/补充工具分级，游戏设计的主工具含 design_agent，前端 Task 的主工具是另一套用不到的就不给）
• 怎么编排思考（原子池和编排表也按 Task 配，游戏设计 Task 里就没有写视频稿子的原子）

第三步：效果——同一个"悠悠"，判成游戏设计时带设计骨架+设计知识+设计工具+设计原子，是游戏设计师；判成前端时带前端那套，是前端设计师。工具、上下文、思考方式全部跟着 Task 走。

上下文模块清单

模块	作用	缺了会怎样
你是谁（人格）	悠悠是协作伙伴不是万能应答机	变成谁都能使唤的问答工具，没立场没判断
对方是谁（铅水画像）	知道偏好、工作习惯、设计立场	只能瞎猜，你否掉方案他猜错原因
怎么做（系统提示）	行为手册，怎么用工具什么能做	Agent 没行为约束，爱怎么来怎么来
当前环境	现在几点、工作区状态、几台电脑	但游戏设计不需要，是噪音
系统结构/工作区地图	资料库/知识库/原子库在哪	不知道去哪找，只能瞎转
设计宪法	不变的立场和判据，最终裁判	今天往东明天往西，没有底线
对话历史（叙事链）	连续性的来源，记忆的落地	但最容易腐烂，要收敛防旧结论干扰
相关通用共识（检索 top3）	当前话题准确检索用得到的共识	Agent 每次要再问一遍
思考工具箱（原子）	按 Task 和思考时刻装配	不会想

Task 机制约等于给上下文也做了一次白盒治理。

---

暴论与收束

Harness 是一个极度个人化、私人化的东西。 不了解他怎么储存记忆、怎么读取知识、怎么思考、怎么使用工具，就没办法真的让他变得更好。

市面通用 AI 产品装的是大多数人的平均数——大众需要写周报他就擅长写周报，大众需要翻译他就擅长翻译。你要做的游戏、稿子、关卡恰恰不在平均数里，平均数里的答案往往是没用的答案。

• 记忆是你的：什么值得记住、哪场讨论改变了方向、哪个决定推翻了从前，只有你知道
• 知识是你的：什么方向对，只有你能定义
• 判断是你的：快乐总量、心流、失败成本，每个词都是从你自己的设计里长出来的
• 方法也是你的：一套体系、一堆原子、一条白盒流水线，装的全是你的判据

通用 Harness 好不好？好，但它装的是大多数人的平均数，而个人要做的设计、个人要走的路恰恰不在平均数里。

Harness 的过程就是把你搬进一个能一直活着的容器里。你的记忆在里面留、你的判断在里面增长、你的思考方式被拆成一张张可以自由排列的卡片，然后他替你一遍一遍地走你走过的路——每一步都比上一次离出口更近。别人给得了你地图，给不了你要去的地方。

prompt: 把agent项目中的体现点 结合这篇文章来说一下

文章在github中已开源，调用生成的架构图示例

附录

相辅相成：Agent的许多设计可以借助游戏设计中的一些算法思想，游戏制作也是一个Agent很好的验证场景

ref：电竞教父_千水老师

排版

很多价值的评定是由差异化决定的，真正有价值的判断，往往在平均数判断之外的地方，所以harness 的 case by case 设计决定了模型的上限
模型只做一件事情：把输入变成输出。而harness改变了 agent 的出发点和方向

• 真正的记忆是一条让存下来的东西流动起来的河
• Knowledge → Method → Skill → Atom