工作笔记 -- 智能体与氛围编程（Vibe Coding）

Posted on June 24, 2025 (twiki)
编程 工作笔记

AI 编程不仅仅是编码领域的事情，而是典型的软件开发，符合软件工程规律。遵守以下流程，不轻易跳步。AI 虽然强大，也受制于你给他什么，Garbag in Garbag out，一步渣步步渣。

未来的软件，不但是给人用的，同时也是给 AI 用的。所以不但要提供 GUI 界面，还须要提供 MCP 接口，以供豆包、元宝之类的 AI 应用直接调用整合。不提供 MCP 接口的软件，会被慢慢淘汰。 AI 智能体（Agents）。它们是计算机，但行为类似人类。它们就像「互联网的灵魂」，需要与软件基础设施交互。所以，我们需要让软件更易于被 AI 理解和操控。

AI 就像新型计算机，LLM 像新的「CPU」。上下文窗口相当于内存；而整个 LLM 则负责在这些资源之间协调内存与计算，以解决问题。

LLM 就像「人类精神」的模拟体 —— 它们是人类的「随机模拟器」。

优点：LLM 拥有百科全书般的知识与记忆能力，远远超过任何单一人类个体。它们可以轻松记住 Git SHA 哈希值、各种信息、文件结构等内容。就像电影《雨人》里的「自闭症天才」，能一字不差地背下电话簿。
缺点：LLM 同时也存在很多「认知缺陷」，比如容易幻觉（hallucination），胡编乱造，缺乏对自身知识状态的良好感知。
智能参差不齐：它们在某些任务上表现超人，但有时却会犯一些基本错误，比如说「9.11 大于 9.9」。这种「锯齿形智能」现象很独特。
前向性遗忘：LLM 不具备持久学习的能力。

我们正在与 AI 合作 —— AI 负责生成，人类负责验证。我们需要尽可能地加快这个生成—验证的循环，这样才能真正提高效率。

加快验证速度。GUI 非常关键。视觉界面能调动人类大脑「图像识别 GPU」，而阅读文本费力又不直观。图形界面是直通大脑的高速通道。
牢牢地把 AI 控制在手上。很多人现在对「AI 智能体」（agent）过于兴奋。但实际上，如果 AI 给软件 repo 提交了 10,000 行代码，那人类审查员就是最大瓶颈：还得逐行确保没有引入 bug，没有安全问题等等。

「与 LLM 合作的最佳实践」：「明确的提示语」（prompt）很关键；如果提示太模糊，AI 可能偏离预期，导致验证失败；一旦验证失败，就要不断试错、反复循环；所以花点时间写更明确、清晰的 prompt，其实是提高效率的关键。

Don’t Build Multi-Agents

Don’t Build Multi-Agents In some cases, libraries such as https://github.com/openai/swarm by OpenAI and https://github.com/microsoft/autogen by Microsoft actively push concepts which I believe to be the wrong way of building agents. Namely, using multi-agent architectures, and I’ll explain why.

https://mp.weixin.qq.com/s/LZcfYqHR2Zl6GnBtzLuMSg 当前流行的多代理框架（Multi-Agent 范式，如 OpenAI 的 Swarm 和 Microsoft 的 AutoGen）违背了 认知可靠性 的基本原理。

AI 代理的根本目标是 在有限上下文约束下完成复杂任务的可靠执行 。而多代理架构在此框架下存在两个根本性矛盾。

上下文碎片化悖论
- 第一性原理：LLM 的决策质量与上下文完整性正相关
决策熵增定律
- 第一性原理：并行系统决策节点数与系统混乱度呈指数关系

构建可靠代理的两个基本规则：

原则 1：全局上下文共享（Full-context Tracing）
- 智能体的每个动作必须基于系统中所有相关决策的完整上下文。
原则 2：决策一致性约束（Implicit Decision Coherence）
- 动作中隐含未明说的决策，冲突会导致系统崩溃。

架构范式建议：从多线程回归单线程

基础单线程：单线程线性智能体（Single-Threaded Linear Agent）
- 所有动作在单一连续上下文中执行（如图示），避免决策分散。
压缩中继：上下文压缩模型（Context Compression Model）
- 引入 LLM（可能是专用 LLM）压缩历史动作 / 对话，提炼关键事件和决策。

架构类型	上下文处理方式	可靠性指数	适用场景
基础单线程	原始全量上下文 -> 信息无损压缩	★★★★☆	中、短任务（10 分钟内）
压缩中继	动态摘要关键决策 -> 信息有损压缩	★★★☆☆	长任务（几十分钟甚至几小时）

DeepSearch 属于单线程，Manus https://manus.im/ 属于压缩中继类型。

进一步探讨：对大模型上下文窗口的影响 当智能体范式从多线程回归单线程，也就意味着未来的大模型需要更关注上下文窗口（支持更长的上下文窗口），正如 Sam Altman 在前些天的一个访谈节目 https://www.youtube.com/watch?v=qhnJDDX2hhU 中提到的那样：

Sam Altman：一个非常小的模型，拥有超人类的推理能力，运行速度极快，有 1 万亿 token 的上下文窗口，并能调用你能想到的所有工具。在这个设定下，问题是什么、模型有没有现成知识或数据，其实都不重要。

Multi-Agent 系统的核心仍然是 Prompt 设计！

Anthropic 实践发现：Multi-Agent 系统的核心仍然是 Prompt 设计！

https://www.anthropic.com/engineering/built-multi-agent-research-system https://cognition.ai/blog/dont-build-multi-agents

像你的智能体一样思考。 要迭代提示，你必须理解它们的效果。使用系统中的确切提示和工具，然后逐步观察智能体的工作。这立即揭示了失败模式：智能体在已经获得足够结果时继续运行，使用过于冗长的搜索查询，或者选择错误的工具。有效的提示依赖于开发智能体的 准确心理模型 ，这可以使最具影响力的更改变得显而易见。
教协调者如何委派任务。 首席智能体将查询分解为子任务，并向子智能体描述这些任务。每个子智能体需要一个目标、输出格式、关于要使用的工具和来源的指导以及清晰的任务边界。 如果没有详细的任务描述，智能体会重复工作、留下空白，或者找不到必要的信息。 最初允许首席智能体给出简单、简短的指令，如“研究半导体短缺”，但发现这些指令往往过于模糊，导致子智能体误解任务或者与其他智能体进行完全相同的搜索。
根据查询复杂性调整工作量。 智能体难以判断不同任务的适当工作量， 因此在 Prompt 中嵌入了调整规则。 简单的事实查找只需要 1 个智能体进行 3-10 次工具调用，直接比较可能需要 2-4 个子智能体，每次调用 10-15 次，而复杂的研究可能需要超过 10 个子智能体，并且每个子智能体都有明确的职责划分。这些明确的指导方针有助于首席智能体高效分配资源，并防止在简单查询上过度投入。
工具设计和选择至关重要。 智能体与工具的接口和人机界面一样重要。 使用正确的工具是高效的 —— 很多时候，这是绝对必要的。 为智能体提供了明确的启发式规则 ：例如，先检查所有可用的工具，将工具的使用与用户意图相匹配，通过网络搜索进行广泛的外部探索，或者优先选择专业工具而不是通用工具。糟糕的工具描述可能会让智能体走上完全错误的道路， 因此每个工具都需要有明确的目的和清晰的描述。
让智能体自我改进。 Claude 4 模型可以成为出色的提示工程师。 当给定一个提示和一个失败模式时，它们能够诊断智能体失败的原因并提出改进建议。 甚至创建了一个工具测试智能体 —— 当给定一个有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过多次测试工具，这个智能体能够发现关键的细微差别和漏洞。这种改进工具易用性的过程使后续使用新描述的智能体的任务完成时间减少了 40%，因为它们能够避免大多数错误。
先广泛探索，然后逐步缩小范围。 搜索策略应该像专家人类研究一样：先探索整体情况，然后再深入具体细节。 通过提示智能体先从简短且广泛的查询开始，评估可用信息 ，然后逐步缩小关注范围，从而抵消了这种倾向。
引导思考过程。 扩展思考模式（导致 Claude 以可见的思考过程输出额外 Token）可以作为一种可控的草稿。首席智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询的复杂性和子智能体的数量，并定义每个子智能体的角色。
并行工具调用改变了速度和性能。 复杂的研究任务自然涉及探索许多来源。为了提高速度，引入了两种并行化：
1. 首席智能体同时启动 3-5 个子智能体，而不是依次启动；
2. 子智能体同时使用 3 个或更多的工具。这些改变将复杂查询的研究时间缩短了高达 90%，使研究能够在几分钟内完成更多工作，而不是像其他系统那样需要数小时，同时覆盖了更多的信息。

References

史诗级预言！Karpathy 演讲刷屏：软件 3.0，人人皆「代码之神」

参考资料快照