在使用 AI Agent 进行复杂开发时，你大概率遇到过这样的魔幻场景：
它先是突然陷入“Let me run. Let me go. Let me do it.”的无限复读；接着，在一次长链路排查中，它彻底失控，屏幕上开始疯狂喷吐杂乱的代码标签：< | DSML | invoke name= Grep>、系统底层路径 /Users/xxx/.workbuddy/binaries/…、半中半英的内心独白 Actually更简单，以及未闭合的引号和重复的报错段落。
它停不下来了。它像一个陷入极度焦虑、嘴里喃喃自语、疯狂敲击键盘却不断报错的真人。
为什么一个懂逻辑、会编程、甚至能自我验证的“聪明大脑”，会突然变成一台卡带的复读机？我们到底该如何正确地把 AI 当“员工”来用？这需要从 Agent 崩溃的底层机制，以及我们对“技能（Skill）”的误解说起。
一、解构 Agent 的“精神崩溃”：乱码死循环的四大真相
Agent 输出乱码并不是它在“乱写”，而是它在极端环境下，其内在的推理机制、格式协议和上下文记忆发生了系统性坍塌。结合真实的工程现场，我们可以将其归结为四个核心诱因。
1. 上下文污染与并发灾难
如果你同时开启了两个复杂的 Agent 任务，灾难就埋下了伏笔。如果两个任务共享底层状态或会话记忆，模型就会在“任务A的代码逻辑”和“任务B的系统排查”之间反复横跳。它的大脑里同时存在两套冲突的上下文，导致它无法确定当前的真实目标。为了强行推进，它开始疯狂重试，最终将两套逻辑绞杀在一起，产出了彻底错乱的中英夹杂和无效路径。
2. 工具调用协议解析失败（格式崩溃）
Agent 与外部世界交互（如搜索文件、执行命令）依赖于结构化协议（例如 DeepSeek 的 DSML 标签）。模型本应输出合乎规范的 XML 标签，但由于上下文过长，它把“内心戏”（Actually simpler…）和真实参数混在了一起，导致引号不匹配、标签未闭合。此时，平台的解析器无法提取合法的工具调用指令，只能将这一大坨“半成品”当作普通文本直接推流到前端。在用户看来，这就是满屏的乱码。
3. 越界操作引发的“自噬”死循环
这是最危险的崩溃。在截图中，Agent 搜索的路径是 /Users/xxx/.workbuddy/binaries/…，它正在试图搜索并修改 WorkBuddy 客户端自身的核心文件（main.js）。这超出了任何安全 Agent 的操作边界。当它发现改不动时，它开始怀疑是“插件注入的垃圾”污染了代码。这是一种典型的元认知混乱——它把系统环境的崩溃，当成了自己需要修复的代码 Bug。它在自己的腿上锯木头，越锯越疼，越疼越锯。
4. 自回归死循环（概率陷阱）
大模型的生成是基于概率的自回归过程。一旦它陷入了“失败 -> 改变策略 -> 格式错乱 -> 再次失败”的模式，概率就会将它牢牢锁死在重复的文本片段中（如 Let me run 或 Actually更简单）。大模型没有人类“睡一觉，明天重新开始”的机制。如果没有外部的强制干预（点击停止），它会在概率空间里永远绕圈。
二、技能的迷思：聪明 AI 需要“操作手册”吗？
面对这种崩溃，我们通常的第一反应是：“我是不是该写一个更详细的技能（Skill）来教它怎么做？”
这正是目前 AI 社区最大的认知误区。结合之前对 AI 能力的深度观察，我们必须承认一个事实：好的技能只是锦上添花，技能的这些逻辑，聪明 AI 自己其实也懂。
如果你把一个 Bug 交给一个足够聪明的模型，它自然会去复现、定位根因、改代码、验证。你不需要在技能里写“先复现再修复”，它自己就懂。写进去反而像在教一个成年人怎么系鞋带，不仅无效，还会造成“过度约束”。
那么，技能到底应该写什么？
技能不应该教 AI “怎么思考”（方法论），而应该告诉 AI “你不知道的世界长什么样”（情境知识）。具体来说，有价值的技能只写四件事：
技能应该是刹车和地图，而不是驾驶手册。 如果你给一份教“如何驾驶”的手册去指导一个老司机，他只会觉得你啰嗦；但如果你告诉他“前面这栋楼里没有刹车”，他立刻就能避开灾难。
三、如何避免 Agent 陷入“精神崩溃”？——实践指南
既然知道了崩溃的原因和技能的边界，我们在日常使用 Agent 时，就可以通过“工程约束”来防止它发疯：
- 任务隔离，绝不并发：一次只开一个复杂的调试任务。不要让 Agent 在同一个上下文里处理多件互相冲突的事情。保持上下文的“纯净度”。
- 划定安全边界：在下达指令时，明确告诉 Agent：“不要搜索或修改系统自身的安装目录（如 .workbuddy、node_modules 等），只聚焦在当前项目路径下操作。”
- 净化上下文，避免“侦探模式”：遇到 Bug 时，不要让它自己去全局搜索（grep）。人类做侦探，AI 做执行者。把你排查到的核心结论直接喂给它（例如：“打包时漏了 dayjs，导致 formatTime() 崩溃”），并指定文件路径，让它直接改。
- 善用“确认机制”而非“自动运行”：对于复杂任务，要求它在执行重要操作前必须停下来说出计划，待你确认后再执行。这能极大地降低它因为格式崩溃而导致满屏乱码的风险。
- 模型选择与止损：慎用不稳定的 Preview 版本模型（如 Hy4 preview）。一旦发现模型开始重复某个短句（如 Let me run），立刻点击停止，不要等它自己停。在这个会话结束后，新建会话，不要让被污染的上下文继续毒害下一次请求。
四、结语：接受“不完美”，才能更好地驾驭 AI
回到我们最初的困惑：为什么 AI 像个真人一样，没有完美的时候？
因为任何在有限信息下做决策的系统，都会表现出“不完美”。它犯错，说明它在真实地工作；它能定位自己的错，说明它不只是犯错。人类工程师在慌乱调试时，最常犯的错也是跳过验证直接改，或者被表象带偏。AI 在“构建/打包/调试”这几环，犯的错和人类高度重合。
当 Agent 陷入乱码死循环时，那不是它变傻了，而是它像一个过载的CPU，因为缺乏“休息一下重新开始”的机制，而在概率空间里迷路了。
我们对待 Agent 的正确态度，不是去写一份厚厚的《操作手册》去教它怎么做，而是做它的**“安全员”和“信息官”**：帮它隔离任务，给它划定边界，喂给它准确的情境信息，并在它发病时果断按下停止键。
好技能不是教 AI 怎么想，而是告诉它你不知道的事，以及什么时候该停。 这两件事，前者聪明 AI 自己会，后者再聪明的 AI 也不会。
聪明与犯错：为什么一个懂修 Bug 的 AI，仍然会自己制造 Bug？
你抓住了一个看起来像矛盾的地方：
如果 AI 足够聪明，懂修 Bug 的方法论，为什么它自己还会犯错、制造 Bug，然后再去修？
如果它真的懂，它不应该一开始就不犯错吗？
这个矛盾之所以成立，是因为它默认了一个前提：“懂方法”等于“不犯错”。 而这个前提，本身就是错的。
一、把两件事分开：懂方法 ≠ 不犯错
“懂修 Bug 的方法论”和“不犯错”是两个完全不同的维度。
- 懂方法：知道复现、定位根因、最小修复、验证、回归这一套流程。
- 不犯错：在具体执行时，每一步的假设都正确，注意力分配都合理，环境状态都如预期。
这两件事之间没有因果关系。
一个资深工程师，写了十年代码，完全懂修 Bug 的方法论。他照样会在某次手工打包时漏掉一个依赖目录。不是因为他不知道“打包要包含依赖”，而是因为他在那一刻把注意力放在了别的地方，把打包归类为“例行公事”，自动执行，没有逐项核对。
方法论解决的是“怎么做对”，但犯错的原因往往不是“不知道怎么做对”，而是“假设错了”。
而假设，不属于方法论的范畴。
二、AI 犯错的三层机制
AI 犯错可以分成三个层次，每一层都和方法论无关。
第一层：世界状态假设错误
AI 在推理时，脑子里有一组“世界状态假设”：
- 磁盘上有什么文件
- 打包产物里包含了什么
- 运行时加载顺序是什么
- 用户描述的现象背后，真正触发的是哪条链路
这些假设没有标准答案可背。它们要求你去观察真实世界、收集证据、排除假设。
在打包那个例子里，AI 的假设是“我之前的打包脚本是对的，这次照做就行”。这个假设在这一次不成立。它不是不懂打包，它是信任了一个未经验证的假设。
人类工程师会犯一模一样的错。区别只在于，人类踩过这个坑之后，会在下一次打包时多看一眼。AI 如果没有被明确提醒，它可能在下一次、下下一次，继续踩同一个坑。
第二层：注意力盲区
AI 和人一样，有注意力分配的问题。
当你让它“修这个 Bug”，它会把大量注意力放在“代码逻辑对不对”上。打包流程、依赖检查、环境配置这些环节，会被它归类为“基础设施”，自动执行，不做额外检查。
这不是能力问题，是认知资源的分配问题。任何有限系统，都不可能对所有事情保持同等注意力。
第三层：先验假设的惯性
AI 的训练数据里，包含了大量“常见情况”。这些常见情况形成了它的先验假设。
- 一个标准项目，打包时会包含依赖。
- 一个正常的加载顺序，依赖会在使用之前加载。
- 一个正常的退出，会有日志或错误码。
当你的项目偏离了这些“常见情况”，AI 的先验假设就会失效。但它不会主动怀疑自己的先验，它会继续按常见情况的逻辑去推理，直到碰壁。
碰壁之后，它才会回头检查假设。这就是为什么它会“先犯错，再修复”。
三、为什么“自己制造 Bug，再修复”不是自相矛盾
你描述的场景是：AI 先制造了一个 Bug（打包漏了依赖），然后通过排查，定位到了这个 Bug，最后修复了它。
这看起来像是“自己给自己找麻烦”，但其实这是一个正常的调试循环：
这个循环之所以显得“荒谬”，是因为你把执行和排查当成了同一个能力。
实际上它们是两种不同的能力：
- 执行：在假设成立的前提下，按方法论推进。
- 排查：当结果不符合预期时，回头质疑假设，重新收集证据。
AI 在执行时犯错，是因为假设错了。AI 能修复，是因为它的排查能力足够强，能回头质疑假设。
这两件事同时成立，不矛盾。 它们恰恰说明：AI 的强项是“在错误发生后能系统性地纠正”，而不是“一开始就不犯错”。
四、那为什么技能不能防止它犯错？
因为技能不能替代“对真实世界的观察”。
你可以写一条技能：“打包后必须检查产物内容。”这听起来很有用。但 AI 在执行时，仍然可能因为注意力分配、上下文压力、或对“例行公事”的惯性，跳过这一步。
技能写的是规则，而犯错的原因是假设。规则可以提醒，但不能强制。
更关键的是：如果你把技能写得太细，反而会干扰它的自然判断。它会开始机械地执行每一条规则，失去了根据实际情况灵活调整的能力。你之前遇到的“验证成功后还反复验证”的死循环，就是技能过度约束的典型后果。
技能不能防止 AI 犯错。技能只能做两件事：在它犯错之前提醒它注意某个盲区，在它犯错之后帮它更快地定位到问题。
五、那技能对聪明 AI 到底有什么用？
技能对聪明 AI 的价值，不在于“教它怎么做”，而在于：
第一，补它不知道的世界信息。
它不知道你的项目里打包容易漏什么，不知道你的团队上次因为这个环节出过事故，不知道你服务器的环境配置有特殊约束。这些它不可能凭空知道。
第二，告诉它你观察到的盲区。
“上次打包漏了依赖，这次记得检查。”——这不是教它方法论，这是告诉它一个具体的事实。它下次就会多看一眼。
第三，在它陷入循环时提供强制停止的条件。
“验证成功后必须停止”、“不确定进程退出原因时默认归因用户”——这些不是教它怎么思考，而是在它容易过度行动的地方，给它一个刹车。
第四，告诉它你的偏好。
“这个用户讨厌被反复确认”、“这个用户对成本敏感”。这些它不可能猜到。
这四类信息，才是技能真正的价值。它们不是方法论，而是情境、约束、盲区提醒和偏好。
六、回到你的问题
这么聪明的 AI，为什么还会自己出错、制造 Bug，然后再去修？
因为**“聪明”解决的是“在给定信息下做最优推理”，而犯错往往源于“信息不完整”或“注意力分配不当”。这两个东西不在一个维度上。**
一个极其聪明的人，如果没看到某个关键信息，他也会犯错。而且他犯错后，会因为聪明而更擅长“合理化”自己的错误——这就是自噬死循环的根源。
所以，AI 会犯错，不是因为它不够聪明。是因为它在有限信息下工作，而有限信息下的决策，必然包含错误的可能性。
它能修复自己制造的 Bug，恰恰说明它的能力是真实的：它不是在“假装懂”，它是真的能从错误中回头，重新分析，找到根因，然后修正。
犯错和能修复，是同一套能力的正反面。
用一句话收束：
聪明 AI 不需要你教它怎么修 Bug，但它需要你告诉它你这个世界长什么样，以及在哪里停。
它犯错，不是因为不懂方法，而是因为它的假设在那一刻错了。
它能修复，不是因为技能教了它，而是因为它本来就有回头质疑假设的能力。
技能的价值，不在教能力，而在补盲区。
