对“长期运行会话”、“生活伴侣”、“LLM-Wiki”、“记忆”的实用批评。解决方案：不可变反思、基于问题和任务的临时会话链、提示模板、独立批评、原型

对“长期运行会话”、“生活伴侣”、“LLM-Wiki”、“记忆”的实用批评。解决方案：不可变反思、基于问题和任务的临时会话链、提示模板、独立批评、原型。 这些只是我个人的看法——我非常欢迎讨论。至少存在以下问题： 陈词滥调： 1. 隐私——透露如此多的个人信息、不断叙述、将其存储在你的计算机文件中，是否值得付出成本？ 2. 个人成本效益分析——你的时间和注意力是有限的。你是否更该做其他事情，比如专注于低层次任务？ 3. Token 成本——即使 Token 越来越便宜，需要迭代和维护的工作所累积的成本仍然远高于一次性完成的简单任务。 4. LLM 的统计本质——这是在交给它的任何任务之上都要支付的固定成本。 5. 默认情况下，大多数情况下可能如此：简单更好，少即是多。更少的维护，更少的投入。 实际原因： 6. 过时——大多数信息会变得过时/陈旧。你所说的一切都会随时间而过时。这需要不断更新，并意味着成本。保持信息更新是不可能的。这与系统维护总问题相关。在某个时刻，你会问自己：你是在做任务，还是在管理本应做任务的系统？ 7. 意图丢失——任何经过 LLM 的东西都会部分混入“糟粕”。你的原始意图如果纯粹，一旦经过 LLM，其特性就会部分丢失。一次经过 LLM 没问题。但让 LLM 策展一个 LLM-Wiki，就是在招致意图丢失和信号丢失。 8. 独立性——一个知道你能告诉它的一切的代理，并不总是比一个什么都不知的代理更有用。是的，一个完全独立、零记忆的代理也不是解决方案，但你的输入所导致的偏差对它来说不一定是好事——这取决于你讲话中信噪比有多高。 9. 模型过载——随着上下文增长，模型会变得愚笨得多。多个任务并行交给模型，会使其尝试推断不必要的关联，从而聚焦于噪声。 10. 知道部分错误的东西，往往比什么都不知道更糟糕——如果你向 LLM 呈现的东西部分过时或错误，它会偏向于那个解决方案。 11. 翻译错误——你甚至不知道你的生活是什么。那么你描述它的方式并非你所了解的它。模型理解它时，又并非你所说的它。它记下的并非它理解的。它更新时又并非它实际变化的样子。其记忆所言，并非当它需要理解时所理解的它。在此之上应用 LLM 的统计本质，你就得到了泥浆。 12. LLM 会偏向于已经说过的话。这并不总是坏事。问题是垃圾进垃圾出。需要确保源质量，这又是另一项成本。源越多，质量越低，因为策展大量源有问题；少量源你可以亲自或密切策展。 13. 部分理解——除非你逐字告诉 LLM 你说过的每一个词，否则它永远不会知道一切——如果它不知道一切，它就必须假设。如果它需要知道一切才能有用，那么它就不是工具，而是一个需要维护的系统。 14. 无论如何，代理不应被允许做出战略决策，你应掌握控制权。那么，如果它只是用来引导、做顾问，那么告诉我：一个知道你所有言行的谄媚者，还是一个独立的领域专家，哪个是更好的顾问？我认为独立的领域专家默认是更好的对话者。 15. 工具选择是开销——这是无意义的元认知。为什么代理需要了解你的 30 个 MCP 服务器和 30 个工具？让它直接干活就行。 16. 代理间通信是开销。这只是代理们扮演组织角色的内耗。组织之所以如此，是因为人际问题，而这通常不适用于 LLM。 17. 推理污染执行——让一个工人先推理他的工作再执行，会导致大量冗余上下文。而且，如果分派的任务写得很好，工人并不需要知道为什么要做这个工作。 18. 不要让代理在没有明确反馈的情况下陷入“自我改进”循环。“自动研究”可能是个好主意，但“我们正在抽象地优化，使系统越来越偏向于某种持续传播的过去解释”，这完全不实用。那只是彻底丢失了用户原始意图的糟粕。 19. 将用户意图与 LLM 生成的输出分离。我认为最优方法是这样做：获取用户所说的 + LLM 通过对话添加的内容，彻底审查一遍，去除糟粕，明确最重要的方向。将其存储为一条不可变的反思，并意识到它会过时。这至少保留了意图，至少没有糟粕。 20. 上下文污染——任何不是信号的东西都会稀释信号。工具调用、高谈阔论、模糊的转述、礼貌用语——这些都通过挤占信号而带来默认成本。 21. 在想法尚未完全成熟之前过早批评也不好，这就是为什么调用独立代理应该是可选的、选择性的，而非强制和持续的。 22. 上下文效率——随着上下文增长，模型会变得越来越愚蠢。 23. 文件越多，模型越有可能开始把一个文件中的糟粕涂到所有其他文件中。“文件 1 里的这个东东文件 2 没有，让我放进去，我多有用啊！”（kappa） 24. 如果你告诉代理不要做什么，它就会做相反的事。你不想它做相反的事，你想它做正确的事。任何指令都是一把双刃剑。因此，并非显而易见地，更多指令就更好。 解决方案： 1. 默认依赖全新的、绑定任务的会话，只进行最小规模的目标交接。 2. 不要使用“代理”，使用“技能”。拥有大量好技能，并学会在什么情况下使用哪个。技能能节省你需要重复说的词。技能能帮助你随着时间略微改进方法。技能越多越好，只要是你调用它们，而不是模型调用。说实话这挺搞笑的，因为那并不是技能本来的定义。是的。应该有一些“宏”的概念，也就是提示模板，区别于技能——不允许模型随意调用这些提示模板。不让代理随意使用技能（除非明确请求），这应该是一个真正的功能。 3. 不要使用“用户”或“记忆”或“LLM-Wiki”，而是使用你所有反思的库，旨在保留你的意图。反思应陈述：考虑了什么、为什么、拒绝了什么、为什么、假设了什么。反思是不可变的。只有当你要求时才会调用反思。模型绝不应该主动搜索它们，因为它们太过偏向且太过时。你可以在不想重复之前说过的话时，让模型去找它们。你可以标记一个词/短语，例如 #context-pollution，然后有一个技能让代理 grep 遍历反思库，从而找到你的意思，而不必再说一遍。 4. 不要让代理端到端地执行一个任务。使用基于任务的上下文擦除会话，比如珠子（beads）或 GitHub Issue。 5. 自己决定何时谈论“为什么”，而不是一味追求“做什么”。不要让代理自主决定何时有用。让它提示，但不要让它决定。 6. 为所有这些（可能还有更多）准备好技能/提示模板：帮助决策（通过提出好问题、生成替代方案、质疑假设、脚踏实地、构建原型/MVP、手段与目的、识别虚假窄化/代理目标、识别可逆的低成本原型），并自己使用这些技能，不要要求模型使用它们。 我并非指：\- 总是从头开始新会话而不带任何...