设计理念

Documentation Index

Fetch the complete documentation index at: https://docs.fim.ai/llms.txt

Use this file to discover all available pages before exploring further.

FIM One 的 DAG 执行引擎设计时采用了刻意的克制。评估了多智能体框架中常见的几种模式，并有意将其排除。本页记录了这些决策及其背后的推理。

​

交接 — 不需要

模式：智能体之间的显式任务交接，其中一个智能体完成其工作并将控制权传递给下一个。 排除原因：DAG 线性链已经自然地覆盖了顺序任务交接。当步骤 B 依赖于步骤 A 时，执行器等待 A 完成，然后通过依赖机制将 A 的结果传递到 B 的上下文中。这在结构上等同于交接 — 但无需单独的抽象层。 添加显式交接协议会重复步骤依赖已经提供的功能，没有增加额外的表达能力。

​

回流 — 不需要

模式：下游步骤将结果反馈给上游步骤进行重新评估（也称为结果的反向传播）。 排除原因：PlanAnalyzer 重新规划循环已经涵盖了这个用例。在所有步骤完成后，分析器评估原始目标是否已实现。如果未实现（且置信度低于停止阈值），它会使用前一轮结果的上下文触发完整的重新规划 — 包括哪些地方出错以及学到了什么。 这是一种粒度更粗但更稳健的方法，相比逐步回流。逐步回流会创建复杂的反馈循环，难以调试，可能导致无限循环。重新规划循环通过更清晰的执行模型实现相同的纠正效果：规划、执行、评估、必要时重新规划。

​

团队（智能体间通信）— 不需要

模式：多个专业化智能体在执行期间相互通信、协商子任务所有权或在共享状态上协作。 排除原因：DAG 依赖链足以满足数据依赖任务的需求。当步骤 C 需要步骤 A 和步骤 B 的结果时，依赖边直接表达了这一点。步骤 C 在其上下文中接收 A 和 B 的输出 — 不需要智能体间消息传递协议。 DAG 模型比智能体间通信更简单、更可预测。智能体无需协商；规划器预先确定执行结构，执行器通过依赖解析强制数据流。这避免了多智能体消息传递引入的协调开销和非确定性。

​

agent_hint / role_hint — 不需要

模式：一个明确的提示，告诉执行器哪种类型的智能体或角色应该处理每个步骤（例如，“使用研究员智能体”或”使用编码员智能体”）。 为什么被排除：三个现有字段的组合已经提供了充分的指导：

• task — 对步骤应该完成的工作的自然语言描述。一个写得好的任务隐含地表明了所需的专业知识。
• tool_hint — 建议步骤应该使用哪些工具（例如，web_search、python_exec）。这比模糊的角色标签更精确地限制了执行方法。
• model_hint — 控制步骤是否使用快速或推理模型层级，这是最具影响力的执行决策。

添加 agent_hint 或 role_hint 会与这三个字段冗余，并会引入规划器 LLM 必须正确处理的另一个配置轴。保持提示表面积小可以减少规划错误。

​

深度多智能体编排 — 战略性延迟

上面的”Teams”排除是一个工程论证：DAG边已经表达了数据依赖关系。本节添加了一个战略性论证：行业趋势是模型能力吸收编排复杂性。

​

为什么模型正在吞噬编排层

多智能体层级结构曾是解决模型限制的变通方案——如果一个模型无法处理复杂任务，你就会将其分解到多个专门的智能体中。每一代前沿模型都在侵蚀这一理由：

​

深度的成本

即使模型缺乏能力，深层智能体层级也会带来复合成本：

• 令牌倍增 — 每个嵌套级别都会重新注入系统提示和上下文。三层深度时，总令牌支出可能是单智能体方法的 5-10 倍。
• 延迟堆积 — 每个级别都是一次完整的 LLM 往返。用户需要等待最慢的链。
• 信息有损压缩 — 委派的智能体返回摘要，而非原始数据。每个级别都会丧失保真度。
• 调试不透明性 — “哪个级别误解了任务？“在深度 > 2 时几乎无法诊断。

​

FIM One 的定位

通过 CallAgentTool 进行一级委派是最佳平衡点：“我是通才，但这个子任务需要 SQL 专家。“这涵盖了绝大多数现实世界的委派需求，同时避免了更深层级的复合成本。 深度多智能体编排被无限期推迟——不是因为难以构建，而是因为前沿模型的发展轨迹表明它将变得不必要。FIM One 的价值在于工具供应层（连接器、MCP、治理），而不是模型正在快速内化的编排深度。