这套方案的出发点是一个简单的问题——如何把单次 LLM 调用扩展成一个能规划、能执行、能恢复、能自证的系统。答案是“组合”：用多个小而可测的原语，通过一个很薄的编排层串起来。每个原语都对应一种“幼稚智能体”的典型失败模式。

类型化工具。 LLM 经常会编造不存在的工具参数。与其在提示词里写死参数格式，不如用 Pydantic 这类数据模型给每个工具声明参数结构，让模型输出自动校验。工具注册时还要带上成本提示，方便后续做预算控制。

规划 DAG。 naive 智能体按顺序执行工具调用，但很多子任务其实互不依赖。方案让 Planner 先输出一个依赖图（DAG），把可以并行的节点同时跑起来。以“对比三座城市”为例，人口、时区、城市摘要这九次查询彼此独立，可以并发执行，最后由聚合节点汇总报告。并发能显著缩短等待时间，但方案也加了信号量限制最大并发数，避免一次性触发太多 LLM 调用导致限流或成本暴涨。

分层记忆 + 检索预算。 把所有历史记录、工具输出都塞进上下文，既浪费 token，也会稀释模型对当前目标的关注。方案把记忆分为工作记忆、语义记忆和情景记忆，并设定一个字符预算硬上限。检索时优先拉取与当前目标最相关的情景记忆，预算耗尽时显式截断，而不是悄悄丢掉关键信息。对语义相似度，使用 384 维的句向量，而不是简单的词袋匹配，因为“法国著名地标”和“埃菲尔铁塔”在字面上几乎没有重叠。

多级验证。 不是每个错误都值得让 LLM 当“裁判”。方案把验证拆成两层：先跑廉价、确定性的结构检查（比如报告是否遗漏了请求的城市），只有幸存者才进入昂贵的 LLM 评审。这样可以在零 token 开销的情况下拦截大量常见错误。

角色分离。 同一个提示词既做规划又做执行又做反思，容易互相干扰。方案把任务拆给三个角色：Planner 负责根据目标和工具列表生成 DAG；Worker 负责执行；Critic 负责判断结果是否合格。每个角色有独立的系统提示词和职责边界。

多维预算。 成本、延迟、token 用量都可能失控。方案给每个节点标注成本提示，并在运行时监控多个维度，超过阈值时触发优雅降级，而不是等到账单爆炸才反应过来。

为了让这套系统可测试、不绑定厂商，方案还引入了一个 LLMProvider 抽象层和一个 MockProvider。前者可以接入 Anthropic、OpenAI 等不同后端；后者在测试时返回确定性的伪输出，让开发者分清到底是编排逻辑出错，还是模型本身规划得太差。

这些组件单独看都不算新奇，但组合起来的思路很清晰：智能体的可靠性不是模型的“智商”问题，而是工程的“结构”问题。

来源：Data For Science / Bruno Gonçalves