Appearance
Agent 怎么设置？
导读
Memory 关掉；权限弹窗选全自动，边界交给沙箱和提示词；MCP 和 Skill 越少越好；soul.md、user.md 不要写；全局守则守底线、项目守则记踩坑，能不写就不写。
这一篇把几个开关一次定下来：Memory、权限弹窗、插件和项目守则。设置的原则只有一条——把上下文留给任务本身，而不是留给你的控制欲。
Memory：关掉
Memory 功能能发挥作用的前提，是它无限接近你所看到的世界，差一点都是 0。
「让 AI 记得更多」满足了我们对「AI 终于认识我了」的情感期待，但在工程上，Memory 机制是：把重要的东西写进外部文件，下次对话时检索出来，塞回上下文窗口。
问题就出在「重要的东西」「检索出来」「塞回去」这三处，每一条都藏着巨大的不稳定性。而这套机制唯一的确定性，是我们都不想看到的：上下文窗口就像一辆座位有限的公交车，被疑似是噪音的历史投影挤占了。
简单任务里你感觉不到，到了复杂任务，它就会干扰 AI。
大厂还在做 Memory，不代表它对
行业已经在退潮，只是那些只会喊口号的自媒体还没收到通知。
如果你关注过 OpenClaw 这个产品，会看到一个很有意思的轨迹：它最初是个记忆完美主义者（SOUL + USER + MEMORY 三件套），后来的更新方向变了——从「有事翻笔记」的被动记忆，转向用 hooks 逻辑自动处理记忆的保存与衰减，并把上下文管理抽象成可插拔的 Context Engine。
它正在从「记忆完美主义者」退回到一个更诚实的立场：记忆不是越多越好，而是「记住、更新、遗忘」三件事的平衡。
一款国产办公向 Agent 的记忆功能默认开启、门槛低、国内占用率高。但它的官方文档里有一句关键的话：
记忆由模型基于会话内容自动抽取，可能存在概括偏差或时效性问题，在依赖记忆做重要判断前建议先核验。
产品方自己都在承认记忆不可靠，只是这句话不会出现在教程标题里。
持久记忆还是一个结构性的安全攻击面。 Memory 文件在每次对话时都被加载进上下文，这意味着任何能修改这些文件的人（通过提示注入、恶意技能或直接文件访问），都能持久性地改变 Agent 的行为。当你看到「让 AI 记住更多」的教程时，教你的人大概率不会提到：你正在为攻击者创建一个持久的、跨会话的行为后门。
权限弹窗：选全自动
正确的做法是：用「专属沙箱」（Agent 的工作区机制）划定物理边界，用「明确语义」（写提示词别含糊）对齐执行意图，让 AI 在安全围栏内拥有充分自主权。
权限弹窗的本质，其实是厂商的免责声明：把「系统安全模型」生硬地套在「智能体协作模型」上。这既是厂商的免责护身符，也是用户体验的绊脚石。
把权限开放给 AI，转而规范对 AI 的命令和设定，才是正解。
限制权限是旧时代的遗老，它基于沙箱机制的「不信任代码」原则设计。但 Agent 不同：
- 语义鸿沟：用户点「允许访问文件」，心里想的是「帮我整理桌面」，但 Agent 拿到权限后可能去删了系统日志。权限粒度与用户意图完全不匹配。
- 上下文缺失：弹窗是静态的，Agent 的任务是动态的。第 3 步需要的权限，在第 1 步弹窗时用户根本无法判断是否合理。
- 责任错位：厂商通过弹窗把「判断风险」的责任甩给了用户。用户为了效率盲目点「允许」，出了事又是用户的锅。
插件：越少越好
MCP、Skill，以及各种插件，原则只有一条：越少越好，千万别囤。
一半以上的外挂只能提供情绪价值，精品也就那几个。MCP 和 Skill 各有专门章节细讲。
另外，Skill 和 MCP（Server）只是碰巧触发机制一样，完全不是一回事，不要放在一起讨论。
soul.md 和 user.md：不要写
SOUL + USER + MEMORY 三件套是前朝遗老，目前还在用的只剩三件套的发明者 OpenClaw，和少数国产办公向 Agent。主流 Agent 框架早已不再把人格定义和用户画像当作独立的持久化文件来强调。
很多自媒体会忽悠你：写一段精心设计的灵魂提示词（Soul Prompt），就能唤醒 AI 的潜力，让它变聪明。这完全是对大模型底层原理的无知。
如果真存在某种能让 AI 瞬间变聪明的「神奇提示词」，模型厂商在 SFT（监督微调）阶段就会把它喂给模型，让自家模型在竞争中脱颖而出。即便有真正有效的进阶技巧，也会以令人眼前一亮的方式由官方或顶尖研究者发布，而不是轮到半吊子自媒体通过玄学话术、包装成「赛博修仙秘籍」来卖课给你。
这家厂商之所以还在坚持，是因为它的企业级记忆框架要借自家 Agent 的用户基数做测试开发；同时这款 Agent 最近也接入了通用的项目守则协议，来弥补 Memory 机制的不足。
站在用户的角度，Memory 机制除了搜集你的信息给厂商做训练以外，看不到有什么用处。
两份守则文件，分别管什么
全局文件是你的「个人宪法」，项目文件是「地方法规」。
几乎所有主流 Agent 都认项目根目录下那一份常驻说明文件，它是通用入口。你不需要去记各家工具的专有文件名，统一用同一份即可——哪天换了软件，它还能接着用。
| 文件位置 | 如何生效 |
|---|---|
| 全局守则文件 | 作为系统级上下文，自动注入你发起的每一次对话中 |
| 项目守则文件 | 仅当 AI 读取当前项目目录时，才作为会话上下文注入 |
项目级：越晚越好，当成踩坑库写
项目初期需求模糊、逻辑未定，这时写下的规则大概率是过时的猜测。AI 会把这份「过期地图」当作真理画地为牢，反复阻碍你的项目进展。
唯一的标准：同一个地方，你纠正过两次以上。
- 纠正过一次的不算：那可能是 AI 的随机抽风，不是系统性偏差。
- 纠正过两次以上的才算：说明这里存在一个 AI 无法靠自身推理跨越的认知鸿沟，必须用显式规则填上。
- 写成可执行的指令，不写成愿望：「注意代码质量」是愿望，「新增接口一律写在
app/api/目录下」是指令。
项目级守则文件不是项目说明书，是故障复盘手册。它不应该指导 AI「应该怎么做」，而应该记录 AI「曾经做错了什么」。好的项目规则永远是长出来的，不是设计出来的。
全局级：越少越好，只守底线
全局文件是常驻 Token 消耗者。你写的每一个字，都会在未来成千上万次对话中被重复计费、重复占用注意力窗口。
- 只写跨项目不变的绝对底线：语言偏好、安全红线、不可逾越的代码规范。
- 处处都成立的等于没说：「保持礼貌」「认真一点」这类话，现代模型在训练阶段已经内化，再写一遍除了稀释关键指令权重外毫无意义。
- 多写一条只对某个项目成立的规则，它在其他所有项目里都是噪音**：上下文预算的纪律。
全局还是项目：能不写就不写
注入的规则越多，AI 越保守，回答质量会疯狂下降。
上下文窗口是有限的「工作记忆」：规则占得越多，留给当前任务推理的空间就越少；约束条件越密，AI 为了满足所有约束而回避风险的倾向就越强——它宁可给出平庸但安全的答案，也不敢越雷池一步给出真正有创见的解法。
这份守则的终极心法不是「写什么」，而是「忍住不写什么」。 每一条规则都要问自己：如果不写，AI 是不是真的会错？如果答案是「可能错也可能不错」，那就别写。把上下文留给任务本身，而不是留给你的控制欲。
写完规则，先测它有没有约束力
写完规则，扔给 AI 一个固定的提示词：
text
① 歧义性：有没有未界定的词，可能导致多种理解？指出具体词语。
② 约束力：换到另一个完全不同的项目，这条规则是否依然成立？如果成立，说明它缺乏项目特异性。
③ 冲突性：这条规则是否与我已有的其他规则矛盾，或在特定场景下无法同时满足？
④ 可验证性：能否用一个明确的"是/否"或客观标准来判断AI是否遵守了这条规则？如果不能，说明它是主观愿望而非可执行指令。
⑤ 冗余性：这条规则是否已经在系统提示词、工具默认行为或代码库本身中隐含存在？如果是，删除它不会改变AI的行为。冒号后面的解释是给你看的，机器不需要。你只需要记住这五个词：歧义、约束力、冲突、可验证、冗余**，它们分别对应 LLM 指令遵循失败的五个根本原因。
- 歧义、约束力、可验证：分别对应语义层、作用域层、执行层，这是人类理解规则时最自然的三个维度。
- 冲突、冗余：对应机器特有的两个故障模式，注意力竞争与上下文窗口的物理限制。
TIP
这一章提出的「LLM 指令遵循失败的五个根本原因（歧义、约束力、冲突、可验证、冗余）」，其学术概念散见于各类论文，但将其提炼并重组为这套工程检验框架，系作者独家总结。
此外，「以结果的可验证性为依据，将任务分为简单/复杂，并据此选择大/小参数模型」**的策略，也是作者在实践中总结的原方法论。
本书包含大量此类非标准化的实战内容，旨在为非编程人员提供可落地的工程指导，而非复刻官方文档或学术共识。客观上可能存在与权威资料不一致、或因模型迭代而过时的情况。**欢迎理性拍砖和有秩序的批评。