> ## 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.

# 设计理念

> DAG 执行设计期间做出的架构决策 — 我们选择不构建的内容及其原因。

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边已经表达了数据依赖关系。本节添加了一个**战略性**论证：行业趋势是模型能力吸收编排复杂性。

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

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

| 模型能力                              | 替代的内容            |
| --------------------------------- | ---------------- |
| 扩展的上下文窗口（200K → 1M tokens）        | 跨智能体分割上下文以适应限制   |
| 扩展思考 / 思维链                        | 显式规划器 → 执行器智能体管道 |
| 原生智能体循环（Claude Code、Codex）        | 框架编排的多步执行        |
| 原生多智能体协议（Google A2A、OpenAI Swarm） | 框架级智能体协调         |

### 深度的成本

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

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

### FIM One 的定位

通过 `CallAgentTool` 进行一级委派是最佳平衡点："我是通才，但这个子任务需要 SQL 专家。"这涵盖了绝大多数现实世界的委派需求，同时避免了更深层级的复合成本。

深度多智能体编排被无限期推迟——不是因为难以构建，而是因为前沿模型的发展轨迹表明它将变得不必要。FIM One 的价值在于**工具供应层**（连接器、MCP、治理），而不是模型正在快速内化的编排深度。
