> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 为什么AI智能体需要结构 - URL: https://www.hubwiz.com/blog/why-ai-agents-need-structure/ - Published: 2026-05-29T15:31:29.000Z - Updated: 2026-10-13T15:47:27.000Z - Description: 借助AI解决问题的五步框架。 - Author: admin - Tags: AGENT, #Import 2026-10-14 14:41 *真实画面：一个AI将研究规格文档交给另一个AI——最终你会明白的。*（在野外能看到这种事情，挺疯狂吧？） 昨晚你给AI智能体一个明确的任务。它努力工作了两个小时。你醒来后看到一份技术正确但完全没用的报告。 这种经历我遇到过太多次，以至于几年前我就不再责怪模型了。失败永远是结构性的，我指的是一种非常具体的、可诊断的意义上的结构性。 AI实验室微调语言模型是为了产生*输出*，而不是质疑框架。这些模型训练背后的整个奖励循环推动它们产生有用的补全；在那个循环中，没有人会奖励一个模型在中途暂停并问"你有没有考虑过你可能在错误地框定这个问题？" **执行**是默认行为。这个设置对于原子任务效果很好：创建一个笔记、写一封简短的邮件、实现一个特定的函数、比较两个明确定义的选项。当真正的问题不是任务本身，而是任务背后的目标时，它会在悄然中、代价高昂地失败。以下是三个例子： 第一：你让智能体为你的Web应用"实现用户认证"。清晰的任务。智能体开始工作，使用JWT令牌、bcrypt密码哈希和会话管理产生了一个技术可靠的实现。 第二：你让智能体"写一份关于可再生能源储能的技术报告"。同样清晰的任务。智能体下载论文、综合发现、产生一份结构良好的文档。 第三：一个家庭让智能体"规划搬到新城市"。随之而来的是详尽的研究——社区、学区、搬家公司、成本估算。每个案例的输出在技术上都是正确的。 每个案例中，提问者最终得到的都是不太合适的东西。所要求的和所需要的东西之间的差距——就是本文要讲的。 *结构是问题所在，不是模型。* 不是模型的智能，不是你提示词的质量，不是温度设置。你交给智能体的*工作流*的结构才是决定它回答正确问题还是听起来合理但错误问题的关键。在本文中，我将向你展示正确的结构是什么样的。但为了理解*为什么*必须如此，我们需要看看我们是怎么走到这一步的。 业界最初采用的修复方案是规划。它有帮助。但还不够。系好安全带，听我讲故事。 ## 1、先规划，后构建 *结构*是问题所在，不是模型。对吧？所以业界最初采用的修复方案是添加一个**规划模式**。 如果你在过去几年中使用过任何主要的智能体编码工具，你一定见过这种模式。有一个*规划模式*：只读，没有副作用，用于思考任务。然后是*构建模式*：智能体执行。 背后的直觉是合理的——将思考和行动分开确实比将它们压缩成一个连续流要好。当你在同一个过程中混合规划和执行时，智能体会基于它对目标的第一次解读做出不可逆的更改。 规划模式强制暂停。你可以在任何东西写入磁盘之前检查计划、与它争论、修改它。计划是交接链中的第一个具体工件。你可以把它拿在手中——或者至少放在你的屏幕上——就它进行真正的对话。 真正的进步。我不想淡化这一点。但看看搬家案例会发生什么。 智能体产生了一个详尽的计划：比较三个目标社区，比较每个社区的学区，联系五家搬家公司获取报价，估算总搬迁成本，制定时间表。出色的计划。一家人审查后点头表示"看起来不错"，然后智能体开始执行。 六个月后：他们住在一个在纸面上完全合理的城市——除了推动整个搬家的那份工作居然是远程的。他们根本不需要搬迁，或者他们本可以搬到房价便宜一半、学校更好的地方。 计划是正确的。执行是正确的。*目标*是错误的。关键在于：构建计划的智能体从未质疑过"规划搬到城市X"是否是正确的目标，因为从未有人要求它这么做。它采用了提示词的第一个合理解读——"他们想搬家，让我帮他们好好搬家"——在那个框架内自信地规划。 软件认证的例子更短但更尖锐。"实现用户认证"：智能体规划了JWT令牌、bcrypt哈希、会话存储。不错的计划，甚至很合理。对于一个单租户Web应用来说。但这是一个多租户SaaS产品（几十个客户共享同一个运行中的应用程序）。 这个计划永远不会发现这一点，因为没有人告诉规划智能体多租户是一个约束条件。它只是做了被要求的事。 现在，你可能正在形成的反对意见："在批准之前仔细审查该死计划不就行了。"这个反对意见在一定程度上是对的，审查确实重要，但它忽略了一个事实：产生计划的智能体已经*锁定*了一个框架。 它问的每一个问题、提出的每一个权衡、呈现的每一个选项——所有这些都已经被它对目标的第一次解读所塑造。当你审查那个计划时，你审查的不是一组中性的选项。你审查的是一个已经选择自己成功标准的计划。框架是不可见的，因为它从未被明确化。 没有探索的规划会锁定第一个合理的目标。 ## 2、规划之前的研究 再说一遍，*结构*是问题所在，不是模型。下一个显而易见的修复是在规划之前添加一个**研究**阶段。 到2025年中期，严肃的智能体设置中出现了第三种模式。一个*研究阶段*：只读，任务是理解问题空间，而不是产生解决方案。它创建的工件是描述性的，而不是规定性的——一个在任何人决定怎么做之前映射已知信息的文档。 直觉再次正确：如果规划智能体不知道自己不知道什么，它就无法好好规划。研究就是它发现的方式。对于可再生能源报告，详尽的研究可能会发现目标受众是政策制定者，而不是工程师——这会改变词汇、技术深度和文档的开篇框架。 真正的进步，再一次。但仍然不够。 仔细看可再生能源报告。智能体运行了扎实的研究阶段：下载了20篇最新论文，阅读了行业报告，综合了电池储能、氢载体、抽水蓄能和电网级热系统的最新技术。然后它过渡到规划模式——在*同一个上下文窗口*中。问题就在这里：*同一个上下文窗口*。 规划智能体不是一个面对研究报告的新鲜思维。它是同一个智能体，携带着它在研究期间得出的所有结论，现在要决定如何构建工作。如果研究智能体得出"电池储能在能源转型中是核心挑战"的结论，规划智能体就会围绕电池储能来构建报告。不是因为它做了一个新决定——而是因为它从未有机会质疑先前的决定。它只是继续前进。研究很出色。计划自然地从研究中得出。报告回答了研究智能体觉得最有趣的问题。不一定是读者需要被回答的问题。 最好的辩护仍然成立，而研究使它更加犀利。最好的辩护说："仅规划就够了，只需审查计划。"研究证明并非如此——但不是因为规划是错误的方法。研究证明了这一点，因为没有上下文隔离的研究只是把锁定提前了一步。同一个做研究的智能体现在在规划。它无法逃离自己先前的结论，不是因为它不具备抽象推理能力，而是因为那些结论字面上就坐在它的上下文中，塑造着它生成的每一个下一个token。 一个全新的规划智能体，只收到研究报告作为一份干净的文档，可以真正质疑研究是否回答了正确的问题。它可以反驳。它可以说"你的研究大量集中在电池化学上，但我不确定这是否是受众需要的。"做研究的同一个智能体无法做到这一点。真的做不到。 但这里真正关键的一点是：研究给你的是事实；它不告诉你是否在解决正确的问题。把这个想法留一会儿，我们还需要一步。 ## 3、计划之后的审查 *结构*仍然是问题所在，不是模型。为了修复它，我们添加了一个新的、事后看来相当明显的步骤。实现之后的**审查**阶段。 这是一个专门的环节，一个独立的智能体——或同一个智能体在独立的上下文中——根据已知标准评估生成的工件。不仅仅是"代码能运行吗"，而是"代码是否实现了我们的意图"。与实现的区别是真实且重要的。实现智能体在构建；审查智能体在寻找会破坏它的东西。 审查实际解决的确实是真实的问题。软件认证实现经过审查智能体评估后，暴露了真实的问题：JWT过期窗口是否针对威胁模型设置了合适的值？bcrypt成本因子是否为这个硬件调优了？会话令牌在登出时是否真正失效了，而不仅仅是过期了？这些都是新的一次检查可以发现的真实bug。我见过审查智能体发现了第二个人类读者才能发现的那种细微错误——不是因为他们更聪明，而是因为他们在寻找问题而不是构建解决方案。 但看看当审查智能体根据计划评估软件认证实现时会发生什么。 计划说："为Web应用实现基于JWT的认证。"审查智能体确认：JWT正确实现了。使用了bcrypt。会话管理已到位。实现通过了审查。它上线了。 第一个企业客户尝试登录时：没有租户隔离。系统中的每个用户共享一个认证命名空间。审查智能体没有发现bug。实现没有bug。计划指定了错误的东西。而审查智能体无法发现这一点——不是因为它粗心，而是因为审查只检查"我们是否正确实现了计划。"而不是"计划是否是正确的计划。"这是不同的工作。你无法通过审查来弥补错误的规格。 这不是智能的失败。这是审查智能体接收到的东西的后果。它接收到了实现和计划。它无法干净地访问原始的问题陈述——用户实际需要什么，产品中隐含了什么约束，产品服务于一个客户还是一百个共享命名空间的客户。它评估的是工件与计划之间的差距，而不是工件与目标之间的差距。 顺便说一句，人类代码审查者也会以同样的方式失败。代码审查会发现风格违规、差一错误、缺少空值检查。它很少质疑三个sprint前做出的架构决策——那个决策已经嵌入到代码库的每一层中。那种问题需要不同的上下文——不同的会议、设计审查、对规格的新鲜视角而不是对实现的视角。 审查能发现错误，但只能在你在规划阶段锁定的框架内。你无法通过审查来弥补错误的规格。 ## 4、在解决问题之前命名问题 终于，结构*就是*问题所在，不是模型。 研究不问它。规划不问它。实现不问它。审查不问它。问题是：*我们在解决什么问题，我们如何知道自己已经解决了它？* 这不是一个修辞问题。它有具体的、切实的答案。而这些答案应该是一份文档——一个规格说明——在编写计划之前产生。不是在规划期间。不是作为研究的副作用。它自己的阶段。它自己的工件。 一份规格说明回答四个问题，而且只需一页纸就能做到。我们试图产生的确切输出是什么？它必须满足的硬约束是什么？成功是什么样的——具体来说，我们会检查什么来确认？失败是什么样的——什么会让我们说这没起作用？ 这些听起来显而易见。它们几乎从未在规划阶段开始之前被回答。根据我的经验，原因在于它们让人感觉会拖慢进度。它们不会。它们防止在错误方向上工作六个月。把它想成一张你可以贴在墙上的单页纸——在争论输出成功还是失败时你会指着的那种。 回到搬家的案例。在详尽的研究阶段之后——社区数据、学校评分、犯罪统计、生活成本比较——一个规格说明阶段会问：对你们家庭来说，一次成功的搬家是什么样的？一家人面对这个问题坐下来。结果发现他们从未明确回答过这个问题。 丈夫的答案：靠近他年迈的父母，他们住在国家的特定地区。妻子的答案：女儿进入一个有强大艺术项目的特定学区。预算答案：将总住房成本控制在让他们能够维持当前储蓄率的门槛以下。三个明确的成功标准。 研究阶段没有发现冲突，因为它从未被告知它在优化什么。规格说明阶段在计划锁定某个城市之前揭示所有三个标准。规划阶段现在可以做有用的事情：找到满足所有三个标准的城市——或者同样重要的是，发现没有城市满足所有三个标准，在任何人预订搬家公司之前就暴露这个冲突。 软件认证的案例很快。规格说明会问：鉴于产品的客户是谁，为这个产品正确实现的认证是什么样的？答案：必须支持多租户隔离和严格的数据分离、企业客户的SSO、以及只有邮箱登录的免费层。 现在计划可以针对实际产品来编写了。研究阶段关于JWT和OAuth的工作仍然有效；只需要通过多租户的视角来解读——这是规格说明明确化的。 完整的链条，连同其五个具体工件，看起来像这样。 **研究**产生一组源材料加上一份描述性的最新技术报告——关于这个问题空间已知了什么。**规格说明**产生一份成功和失败标准文档。**规划**产生一份具体的分步计划——根据规格，如何从现在到达那里。**实现**产生一个可评估的工件——代码、文档、报告、建议。**审查**产生一份对照规格说明（而不仅仅是计划）检查的评估报告——对"我们解决问题了吗？"的真实回答。 五个文档。五次*交接*。五个在错误框架变得代价高昂之前捕捉它的机会。 ## 5、其实我们一直都知道 有趣的是，所有这些至少在原则上早在1987年之前就已经为人所知了。 IDEO，一个如今超级著名的设计咨询公司，阐述了一个五阶段的创意流程，后来斯坦福的d.school将其编码为**设计思维**。 Tim Brown 在《Change by Design》中形式化了发散-收敛逻辑。五个阶段：**共情（Empathize）**、**定义（Define）**、**构思（Ideate）**、**原型（Prototype）**、**测试（Test）**。如果你觉得这些名字听起来很熟悉，考虑到你刚刚读过的内容，那不是巧合。 共情就是研究：广泛收集，收集上下文，与用户交谈，从外部而不是内部理解问题空间。定义就是规格说明：收敛到一个带有明确成功标准的明确问题陈述，"我们如何可能"的问题，它框定了下游的一切。构思就是规划：再次发散，生成候选解决方案，探索可能方法的空间。原型就是实现：产生一个可评估的工件，可以放在某人手中的东西。测试就是审查：根据问题陈述评估原型，而不是根据原型自身的内部逻辑。 智能体世界自2023年以来一直在添加的每个阶段，早已在一个比现代Web早十五年的框架中被命名、排序和论证。这是一个每个硅谷初创公司、孵化器、加速器和风险投资人都了如指掌的框架。它在全球各地的商业专业中教授。它字面上就是大多数路演演示的结构。但它仍然缺失于我们每天使用的大多数智能体协议中。 最明显缺失的部分是定义阶段——第二个阶段，IDEO把它放在第二是有原因的：没有明确的问题陈述，下游的一切都会回答错误的问题。这是该领域不断从头重新发现的一个非常古老的洞察——Agile的完成定义、测试驱动开发的先写失败测试、示例化规格说明。每一个都是同一个洞察的不同名字。 现在，这是你最初的反对意见最强版本。"你不需要所有这些结构。一个优秀的提示词指定了受众、格式、成功标准、约束。写一个更好的提示词，你就一次搞定五个阶段。" 让我们认真对待这一点，因为它关于提示词质量并没有错。一个精心制作的提示词，指定了输出是给谁的、应该采用什么格式、必须完成什么、什么会让它失败——那个提示词实际上就是一份规格说明。你说得对，提示词质量很重要。 但是一个包含研究上下文、目标规格说明、计划和执行指令的单一提示词并不是五阶段流程的更简洁版本。它是五个阶段折叠成一个上下文窗口，没有任何机制让每个阶段质疑前一个阶段的结论。 当研究和规划共享一个上下文时，规划无法质疑研究。当规划和实现共享一个上下文时，实现无法反驳计划。当规格说明和审查共享一个上下文时，审查已经倾向于确认它帮助编写的规格说明。提示词质量关乎你问什么。 阶段独立性关乎谁来处理每个答案，以及他们是否能真正不同意前一步。你可以写出世界上最好的提示词，但仍然把它交给一个在同一收窄通道中执行的智能体，在每一步都复合相同的假设。 想象一下某个人第五遍读自己的手稿——他们不再看到那里有什么，只看到他们想写的。这是人类心理学中被复制最多的发现之一：一旦我们形成了一个信念，我们就会通过那个信念的视角来解释后续证据。我们注意到确认性的证据，折扣否认性的证据，并生成假设该信念正确的假设。 这不是智能的弱点。每一个心智——人类还是人工智能——都通过它已经得出的结论来解读。研究你问题的智能体已经对它有了信念。当它过渡到规划时，它为那些信念服务地规划。规划过的智能体已经有了一个解决方案。当它实现时，它做出了无数服务于那个解决方案的微观决定。实现过的智能体在工作的过程中维护着选择。当它审查时，它善意地阅读自己的输出。 上下文隔离打破了这条链。一个新鲜的上下文没有看到先前的步骤。它不会被它从未得出的结论所欺骗。它冷读工件，这是真正评估它的唯一方式。 设计思维的发散-收敛逻辑不是关于每个阶段做*什么*。它是关于*谁*来做，以及他们是否能在不继承前一阶段的承诺的情况下得出结论。 ## 6、从今天开始自己实践 手工版本比听起来简单： - **把每个阶段当作一个独立的对话**。为每个阶段开始一个新的会话。 - **只传递前一个阶段的工件**——不是之前的对话，不是你正在运行的上下文，不是你一直在想什么的摘要。只有工件。 - **明确告诉智能体它处于什么模式**。"你处于研究模式。不要提出计划。不要建议解决方案。你的唯一工作是描述问题空间并产生一份研究报告。" 这个指令很重要。不是因为模型需要被控制，而是因为明确的模式分配防止智能体在感觉到需要填补的空白时滑入执行行为。模型被训练为有帮助的；有用性将每个空白推向解决方案。命名模式是你抵抗它的方式。 纪律在于你，不在于工具。这适用于任何智能体、任何界面。新鲜的上下文、明确的模式、工件交接。这就是全部配方。 如果你想走得更远，你可以让阶段在结构上被强制执行而不是仅仅被指示——字面上无法执行的智能体、只接收工件的子智能体、没有共享上下文的自动交接。可编程的harness给你这种级别的控制，每个技能有权限级别。（如果你没有，联系我，[我会免费借你一个](https://apiad.github.io/aegis?ref=hubwiz.com)。） 你今天可以采取的一个小步骤：在你已经在使用的任何工作流中添加一个规格说明阶段。在规划阶段编写计划之前，先要求一份成功标准文档。一页纸。明确的通过/失败条件。什么会使这个输出成功？什么会让你把它扔掉？在规划开始之前审查那份文档。 这单一的添加——在研究和规划之间插入一个定义阶段——比事后添加审查阶段能捕获更多失败。因为它在计划锁定错误目标之前就捕获了它们。 不要做什么：不要把所有五个阶段当作机械检查清单来实现。不要把阶段当作装饰添加——一个与规划共享上下文的研究阶段添加的是对话轮次，不是结构。同一个窗口中更多的文字不是更多的阶段。阶段是上下文边界，不是食谱中的步骤。一个不产生具体工件且不将其传递给新鲜上下文的阶段什么也不添加。 每个阶段一个文档。每个阶段一个新鲜的上下文。就这么简单。 ## 7、在重新提示之前先重构结构 想象工件链是一个物理的东西。一个牛皮纸文件夹从一个办公桌传递到下一个。研究办公桌产生一份报告，合上它，推过去。规格说明办公桌只打开那个文件夹，阅读它，产生一份标准文档，合上它，推过去。规划办公桌从不打开研究文件夹——它只打开标准文档。 依此类推。每个办公桌只看到恰好一份先前的文档。每个办公桌恰好产生一份新文档。链条使独立性成为可能。你无法交接一个模糊的意图。你无法把一种感觉推过办公桌。只有文档。 上下文隔离是大多数流水线跳过的步骤，但它做了最多的工作。每个与前一个阶段共享上下文的阶段都继承了它的承诺。不是因为模型懒惰或错误——而是因为这就是认知的工作方式，人类或其他。我们通过已经得出的结论的视角来解读。 上下文隔离很便宜：开始一个新会话，只传递工件。认知科学是明确的：打破确认偏误链需要结构性断裂，而不是更好的指令。上下文隔离被跳过是因为它看起来是可选的。它不是。 记住，结构是问题所在，不是模型。在重新提示之前先重构。 下次见，保持好奇。 --- 原文链接: [Why AI Agents Need Structure](https://blog.apiad.net/p/why-ai-agents-need-structure?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)