很多人对 LLM 抱有一种近乎许愿机的期待：仿佛只要说上几句话，它就能心领神会，把脑子里的东西原样变出来。

但 LLM 不是许愿机。你说出口的，往往只是心中所想的一小部分；那些没说的、自以为不必说的，甚至自己都没意识到的，它都无从得知。于是它交出的，常常不是你真正想要的东西，而是那一点已知信息所能撑起的、最可能的版本。

要理解这种落差，不妨暂时把 LLM 想成一团概率云：约束不足时，里面包含许多可能的输出；任务开始后，概率云坍缩，其中一种结果被采样出来。用户提供的材料、偏好、上下文和限制越明确，可选范围就越窄，结果也越接近真实意图。

本文借用了「概率云坍缩」和「熵增」作为理解 LLM 的比喻。文中的压缩、转录与补全，是一套用于分析实际任务的信息操作框架，并非香农信息论的正式分类；多步沟通中的误差累积，也不等同于某条可以直接套用的数学定律。

三种信息操作

从信息流动的方向看，我们交给 LLM 的任务大致可以分成三类：压缩、转录和补全。三者对模型提出的要求很不一样。

压缩：从大信息到小信息

这里的「压缩」，更接近摘要、归纳和提炼这种语义上的有损压缩，而不是能够完整还原原文的可逆编码。它可以保留核心结构与主要结论，却一定会丢失一部分细节、语境和可还原性。1 2

LLM 很擅长这类工作。只要给它足够多且足够相关的材料，它就能把大块信息压缩成更小的表达：总结、提纲、要点、结论或决策建议。此时它的优势不是凭空创造，而是帮助人类降低冗余、提取结构。

这也说明了为什么在需要模型准确理解材料时，最好提供原始文本，而不是只给二次转述。转述已经经历过一次有损压缩；再交给 LLM 时，许多原本可以用于判断的细节已经消失。模型无法从摘要中恢复一段从未进入上下文的原文。

转录：在相近信息量之间转换

翻译、改写、把口语整理成书面语、把同一段内容变成不同风格，都可以视为转录。目标不是创造大量新信息，也不是大量丢弃信息，而是在尽量保留原意的前提下改变载体、语言、结构或风格。

LLM 同样适合这类任务，因为它可以利用丰富的语言模式寻找不同表达之间的对应关系。不过，「大致等价」不代表「自动等价」。专业术语、语气、文化背景和隐含立场仍然可能在转录中偏移，所以高要求的翻译与改写依旧需要对照原文检查。

补全：从小信息到大信息

真正麻烦的是从小信息到大信息。

如果只给出一个创意，就要求模型直接写出完整代码；只说一句需求，就让它设计整个产品；只给一个标题，就让它写成长文——模型不可能从这些有限信息中推断出所有真实细节。

于是概率机开始发挥作用。所有没有被明确提供的部分，都会由模型根据训练中学到的模式补全。补全有时很有价值：它可能带来常见的最佳实践、合理的结构和成熟的表达；补全也可能带来误解、事实错误、遗漏的约束，以及本不该被默认的默认值。

补全的一体两面，就是创造与幻觉。开放生成允许多种答案时，我们把新颖而合适的补全称为创造；任务要求忠于事实或约束时，错误补全就成了幻觉。问题不在于模型会补全，而在于我们必须记住：补全不是还原事实，只是在概率空间中选择一种可能。3

创造与幻觉，要到验证时才能区分

在生成发生的那一刻，创造和幻觉其实无法被模型自身可靠地区分。一段内容可能是恰到好处的创造，也可能是煞有介事的幻觉；差别不在生成动作本身，而在它能否经受外部验证。

科学里有「大胆假设，小心求证」的说法。补全对应大胆假设：在信息不足处提出一种可能；让它变成可依赖结论的，是后半句的小心求证。

人脑或许也有相似的一面。那些一闪而过的念头、联想和记忆本身并不可靠。我们之所以敢把某些内容当作现实中的事实，是因为它们能够被记录、证据、他人观察或反复经验从多个角度校验，而不是仅仅「感觉像真的」。

因此，与其把幻觉简单理解为生成能力的缺陷，不如把它看成未经验证的补全。对应的解法不是彻底压制生成，而是给生成接上足够可靠的验证链。针对语义不确定性的研究，也在尝试用不同答案之间的意义分歧来识别高风险输出。4

模型知识，是世界被压缩后的幻影

LLM 并不是空白的。训练过程把一部分世界知识、语言习惯、常见模式和技术套路压进了模型参数，因此我们不必在每次对话里从头解释一切。

但这类知识并不等同于一座可以精确查询的数据库。它更像全人类知识库经过压缩后留下的幻影：上下文给出明确线索时，相关内容可能被有效唤起；线索不足时，它也可能没有被正确调用，或与相似事物发生错误关联。模型还可能不知道知识已经过时。5

所以，「模型应该知道」并不是一个可靠前提。任务一旦依赖具体版本、最新事件、精确数字、项目现状或私人背景，就需要把可信材料重新放回上下文，或让模型通过工具访问真实来源。

两类缺口：人的意图与外部现实

模型缺少的信息通常来自两个方向：一部分只存在于当事人的脑子里，另一部分存在于文档、代码、网页和正在变化的现实中。解决办法也对应地分成两种。

让模型提问，补上意图侧的缺口

我们当然不能把大脑里的全部内容一次性 dump 给模型。那既不现实，也会制造大量噪音。更有效的方式，是让模型反过来「蒸馏」我们：由它提出问题，通过几轮问答迅速收窄可能性空间。

这里最棘手的是「不知道自己不知道」。许多背景在当事人看来太显然，以至于根本想不到要说；模型又无法直接知道缺了哪一块。这个盲区对双方都存在，只是人类通常已经共享了更多生活经验和现场背景，而 LLM 拿到的上下文往往薄得多。

与其指望一次把话说全，不如允许模型主动指出分叉：目标受众是谁？要保留兼容性吗？更看重速度还是质量？哪些结果不能接受？让缺信息的一方提出问题，是打破这个死循环为数不多的办法。

使用搜索和工具，补上现实侧的缺口

另一种办法，是把外部世界直接接进上下文。Exa 这类面向 AI agent 的搜索与网页提取工具，本质上是在给模型注入实时信息：搜索网页、抓取文档、提取相关段落，再把重点材料交给模型。6 7

这对纠正幻觉尤其重要。模型猜测某个 API、新闻、公司、项目或版本变化时，联网检索可以把「我觉得可能如此」改写成「当前资料显示如此」。搜索不会让模型自动变成全知，但它能用来自现实的新信号重新收窄概率空间，减少模型拿过时知识或相似模式硬套现状的机会。8 9

工具也减少了人充当信息搬运工的需要。很多事实并不在用户脑中，即使在，也不该要求用户把文档、网页和版本差异逐字转述。让模型按需读取原始材料，再在当前上下文中压缩、引用和推理，通常比经过多次人工转述更高效，也更容易追溯。10

提问解决「人究竟想要什么」，搜索和工具解决「世界现在究竟是什么样」。两者合在一起，才构成一个比较完整的认知回路。

反馈闭环，才是 agent 的感官

单次 prompt 决定了模型从哪里出发，持续反馈则决定它能不能留在正确的路上。

为什么无限 /goal 不可靠

让 LLM 围绕一个 /goal 无限做事，并非绝对不可行；问题在于，当最初的信息不完整、执行期间又没有持续反馈时，每一步都需要继续脑补。补全得越多，方向漂移的机会就越大。

如果 agent 能持续获得环境观测、测试结果、用户确认、工具返回值、错误信号和阶段性验证，情况会完全不同。人类不是只靠一条最初的目标描述行动，而是通过感官和身体不断接收信号，再让现实修正下一步。agent 也需要类似的回路。11 12

反过来，一个被剥夺所有工具和反馈渠道的 LLM，就像一颗切断四肢五官的「缸中之脑」：它只能在自己的输出里继续推演，也越来越难区分推演与现实。

所以关键不只是运行时间，而是反馈是否足够密集、真实和及时。目标越大、上下文越少、反馈越稀薄，最终结果就越像从概率海洋里随机打捞出的一个样本，而不是稳定、可复现的执行过程。

Plan 模式：在行动前暴露脑补

Claude Code 的 Plan 模式把工作分成两个阶段：先使用只读工具探索现状、制定计划，再由用户确认后执行。13 它的价值不只是限制写权限，而是设置一道「意图对齐闸门」。

需求很短时，模型若直接行动，就会把大量隐藏假设直接写进代码；Plan 模式则要求它先说明：目标是什么、准备改哪里、为什么这样做、如何验证。用户审查计划时，那些藏在概率空间里的补全就被摊开了，可以被追问、否决或修正。错误仍停留在语言层面，修改成本远低于落进文件、依赖和后续推理之后。

Claude Code 的 Ultraplan 把这种机制扩展成可评论、可反复修订的计划审阅流程。14 Superpowers 等 skill 方法论则更进一步，把需求澄清、规格确认、实现计划、测试、检查点和评审固化成工作流。15 16

这类重型流程适合高风险、大跨度、需要长期自治的任务，但不一定适合每个小修改。流程越重，越像给模型外接一套公司制度：它能减少跑偏，也会增加注意力和沟通负担。真正重要的不是仪式本身，而是让流程的重量与任务风险相称。

阶段性同步：在行动中重新对齐

即使计划已经通过，执行过程中仍会出现最初没有暴露的信息。现实里的管理者会定期看进度、听汇报、调整优先级；LLM agent 也需要阶段性同步，而且它行动更快，误差累积也可能更快。17 18

这种同步不必是一场正式会议。它可以是任务列表更新、一组修改后的状态报告、diff review、测试结果汇报，或在关键分叉前请求确认。形式并不重要，关键是让模型持续报告它观察到的现实，并让人的新判断重新流回上下文。

日志：人为接上一条反馈链

调试是反馈闭环最直观的例子。与其让 AI 根据一句「这里坏了」反复猜，不如先在可疑位置增加日志，在问题真正触发时把现场输出原样交给它；模型据此排除一批猜测、缩小范围，再添加更有针对性的观测。几轮之后，现场数据逐步替代脑补，根因也更容易暴露。12 19

日志就像给那颗「缸中之脑」开了一扇窗。它还减轻了人的描述负担：人往往不知道哪个细节最关键，而日志允许现场自己说话，缺哪一段就继续观察哪一段，不必先靠人工穷举所有可能。

程序员的工作，本来就是一条信息流水线

从老板在会上提出的模糊想法，到产品、设计和工程人员反复完善需求，再到代码和最终验收，软件开发本身就是一条信息流水线：

  1. 把发散讨论压缩成需求；
  2. 把简略需求补全成规格与实现；
  3. 把规格转录成代码；
  4. 再通过测试和体验，反向验证结果是否仍忠于最初意图。

LLM 还无法稳定地独自跑完整条流水线，关键不在于它不会写代码，而在于它很少参与信息产生的全过程。开会时它不在场，私下讨论时它没有旁听；公司的目标、团队的历史包袱、每个人的经验和隐性判断，对它来说大多缺失。它拿到的往往只是链条末端被压缩过多次的一小段，却被要求补全全部细节。

验证环节也有同样的问题。单元测试和静态检查可以提供机器可读的反馈，但大量软件体验仍然依赖人的观察：界面是否错位、动画是否自然、交互是否符合预期。模型可以读取截图和录屏，却未必已经拥有像人一样持续、稳定地理解动态体验的能力。于是人类目前仍承担三项关键工作：补充缺失上下文、在不同形态间转录意图，以及完成最终验收。

要让 LLM 真正接管更多流程，缺的未必是更强的生成能力，而是把它接入信息产生的现场，并给它足够可靠的感官和验证手段。

误差如何沿信息链累积

流水线还有一个隐患：每次压缩、转录和补全都可能引入偏差。压缩时少一点语境，转录时偏一点语气，补全时猜错一个默认值——每一步单独看都「大体没错」，串起很多环后，结果却可能离最初意图很远。

这里可以借用「熵增」作为直觉：信息在多次有损处理后，会越来越难恢复到原始状态。但这只是工程上的类比；严格的信息熵取决于随机变量和概率分布，不能把所有沟通误差都直接写成一条物理或信息论定律。

软件开发中常见的 XY problem 就是一个缩影：提问者拿着自己推导到一半的方案 Y 来求助，却没有说出真正想解决的问题 X。接收者只能在一个已经丢失原始意图的中间结论上继续补全。

保留原始意图，而不是只保存摘要

既然 LLM 可以按需压缩，下游结论就不该脱离来源、被当成永恒事实四处流传。系统需要一个保存原始意图和原始证据的 single source of truth，让任何摘要和决策都能追溯回去。

这并不意味着二级结论不能保存。更准确地说，它是一种缓存：价值在于减轻认知和上下文负担，风险在于缓存失效。源事实、用户意图或外部环境已经变化，而摘要没有标注来源、适用条件和更新时间时，它就会从减负工具退化成污染源。

对 agent memory 的研究也发现，缺少生命周期管理的记忆系统容易返回 stale facts，制造所谓「过去的幻觉」；而摘要、压缩与事实抽取的每一层抽象都会继续丢失细节。20 因此，一条可长期使用的二级结论至少应该回答四个问题：它从哪里来、何时形成、在什么条件下成立、什么时候需要重新验证。

多 agent 不该复制人类官僚体系

人类组织发展出多级官僚结构，不只是因为权力，也有现实的信息处理原因。一个人无法同时理解上百人的状态和细节，于是信息需要在基层压缩，由中层汇总、过滤，再变成高层可以处理的少量摘要和选项。

但每多一级，就多一次压缩、转录和补全，也多一个会混入自身偏好与利益的节点。基层可能报喜不报忧，中层可能为了资源强调某些问题，高层再根据已经变形的摘要继续决策。信息链不仅有损，而且并不中立。

把多个 agent 组织成相同的层级，同样可能重演这个问题：一个 agent 向另一个汇报，上层继续总结，最终决策者只看到经过多轮加工的结论。LLM 的压缩能力很强，补全能力也很强；中间层一旦为了让摘要更顺畅而自行填空，错误就可能被包装成确定判断继续上传。21 22

因此，多 agent 系统更需要直接、可追溯的信息通道。中间 agent 可以整理材料、压缩内容、提出建议，但不应成为唯一的信息入口。关键事实、原始证据、用户意图、工具返回值、测试结果和错误日志，应该能被最终决策者直接展开查看。研究也表明，通信拓扑会显著影响多 agent 系统中的信息传播与结果质量。23

理想的协作不是取消分工，而是让每个结论都能回到证据链，每个摘要都能展开为原始材料，每个决策都能追溯到用户最初的目的。

怎样给 LLM 提供信息

核心原则听起来很简单：给模型尽可能多的相关信息，同时控制信息质量。

信息太少，模型只能大量补全；信息很多却不相关，模型会被噪音淹没，有限的注意力无法抓住重点。Context Engineering 的目标，正是在两者之间组织出一个适合当前任务的上下文。24

实际使用时，可以遵循几条原则：

  1. 优先提供原始材料。 能给代码、日志、原文和数据，就不要只给二手总结。
  2. 交代完整的来龙去脉。 用 5W1H 检查 What、Why、Who、Where、When 和 How，尤其不要省略目的、受众与限制条件。
  3. 允许模型提出澄清问题。 当选择会影响兼容性、风险、范围或长期方向时，先对齐再行动。
  4. 让结论附带证据。 搜索结果、工具输出和测试报告应当可以追溯，而不是只剩一句「已经确认」。
  5. 为长任务设置检查点。 在关键分叉、成批修改和高风险动作前后重新同步。
  6. 把验证设计进流程。 事实要查来源，代码要跑测试，界面要做实际验收，不能把生成本身当作完成。
  7. 把摘要当缓存管理。 保存来源、时间和适用条件；源头变化时，让旧结论失效或重新 derive。

纠错时也一样。只告诉模型「应该怎么做」通常不够，那只是一个孤立的下游结论。更有效的反馈会解释：原做法为什么不行、违背了哪条原则、在哪些相似场景中仍然适用。把原因讲清楚，模型才有机会举一反三，而不是机械记住一个特例。

后训练：人类每天都在做，LLM 暂时还做不起

前面的办法都依赖于把信息重新放进当前上下文。另一条路径，是把它直接固化进模型自身。

人的睡眠和长期记忆有一点类似这种过程：白天经历过的内容被反复整理，一部分逐渐沉淀成不必刻意回忆的经验。人类一生都在更新自己，而今天的大多数 LLM 在两次训练之间基本是冻结的。

如果每天为每个用户单独做一次后训练，成本很高，结果也可能迅速与现实脱节。在持续个性化训练足够便宜、可靠之前，更现实的办法仍然是维护高质量、相关、可追溯的上下文。

把反复使用的约定，以及每次纠错背后的理由写进 AGENTS.md、CLAUDE.md 或项目文档，就是一种低成本替代：它没有真的改变模型权重，却让过去的经验在每次任务开始时重新进入上下文，使概率空间一次次收窄到更合适的范围。7

与其许愿，不如接好信息与反馈

说到底，LLM 不是许愿机，而是一台概率机。它交出的永远只是现有信息所能撑起的最可能版本：没说出口的，它只能脑补；没被验证的脑补，就可能表现为幻觉。

真正有效的使用方式，可以归结为两件事：

  • 把相关的信息喂足。 这决定模型需要在多大的范围里猜。
  • 把反馈的链条接上。 这决定它的猜测能否被现实不断修正。

生成能力让模型可以从小信息扩展出大结果，但只有上下文、工具、提问、测试和人的判断，才能让那个结果从「看起来合理」逐渐走向「确实可用」。

参考文献

  1. Claude E. Shannon, “A Mathematical Theory of Communication”, 1948. https://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf ↩

  2. Inferara, “The Fundamental Architecture of LLMs: A Perspective Through Information Theory and Lossy Compression”. https://inferara.com/blog/llm-information-theory-lossy-compression/ ↩

  3. Gerus Team, “LLM Hallucinations Are Compression Artifacts — And That Changes Everything About How We Build AI Products”. https://dev.to/gerus_team/llm-hallucinations-are-compression-artifacts-and-that-changes-everything-about-how-we-build-ai-3gae ↩

  4. Oxford Applied and Theoretical Machine Learning Group, “Detecting hallucinations in large language models using semantic entropy”. https://oatml.cs.ox.ac.uk/blog/2024/06/19/detecting_hallucinations_2024.html ↩

  5. 阿里云开发者社区，《LLM 幻觉问题：来源与早期研究_深度解析》。https://developer.aliyun.com/article/1683987 ↩

  6. Exa, “Web Search API, AI Search Engine, & Website Crawler”. https://exa.ai/ ↩

  7. Anthropic Engineering, “Effective context engineering for AI agents”. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩ ↩2

  8. “Hallucination Mitigation for Retrieval-Augmented Large Language Models: A Review”. https://www.mdpi.com/2227-7390/13/5/856 ↩

  9. Peng et al., “Check Your Facts and Try Again: Improving Large Language Models with External Knowledge and Automated Feedback”. https://export.arxiv.org/pdf/2302.12813v3.pdf ↩

  10. Elasticsearch Labs, “Context engineering vs. prompt engineering”. https://www.elastic.co/search-labs/blog/context-engineering-vs-prompt-engineering ↩

  11. Manus，《AI 代理的上下文工程：构建 Manus 的经验教训》。https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus ↩

  12. Daniel Demmel, “Feedback loop engineering”. https://www.danieldemmel.me/blog/feedback-loop-engineering ↩ ↩2

  13. Claude Code Docs, “How Claude Code works”. https://code.claude.com/docs/en/how-claude-code-works ↩

  14. Claude Code Docs, “Plan in the cloud with ultraplan”. https://code.claude.com/docs/en/ultraplan ↩

  15. obra/superpowers, “Superpowers”. https://github.com/obra/superpowers ↩

  16. Claude Code Docs, “Extend Claude with skills”. https://code.claude.com/docs/en/skills ↩

  17. Arize AI, “How to Build Planning Into Your Agent”. https://arize.com/blog/how-to-build-planning-into-your-agent/ ↩

  18. SOTA Sync，《长任务 Agent 的最小工程闭环：三层五态控制架构》。https://sotasync.com/reader/2026-05-24-long-task-agent-engineering-closed-loop/ ↩

  19. Lumina，《智能体编排工程：LLM 作为新一代操作系统》。https://lumina.shawnxie.top/article/agentic-harness-engineering-llms-as-the-new-os-b2a6dc11 ↩

  20. Zhou et al., “Are We Ready For An Agent-Native Memory System?”, 2026. https://arxiv.org/abs/2606.24775 ↩

  21. “Communication Overhead in Multi-Agent LLM Systems Grows Quadratically with Agent Count”. https://www.clawrxiv.io/abs/2604.00736 ↩

  22. “Beyond Tokens: A Unified Framework for Latent Communication in LLM-based Multi-Agent Systems”. https://arxiv.org/html/2606.05711 ↩

  23. “Understanding the Information Propagation Effects of Communication Topologies in LLM-based Multi-Agent Systems”. https://arxiv.org/html/2505.23352 ↩

  24. Prompt Engineering Guide, “Context Engineering Guide”. https://www.promptingguide.ai/guides/context-engineering-guide ↩