尧图网站建设 
1. 三层架构到底在吵什么Harness、Loop、Graph 的边界Agent Harness、Loop、Graph 这三个词经常出现在同一场技术讨论里很多人把它们当成近义词换着用。但如果你正在做多工具接入 AI 能力的开发混用这三层会直接导致架构决策跑偏。我用一句话帮你先记住Harness 管环境Loop 管反馈Graph 管流程。它们相互嵌套但不能彼此替代。具体来说Agent Harness 是包裹在模型外部的运行系统决定模型在什么环境里工作——有没有文件读写、能不能调 Shell、状态能不能跨会话保存、权限边界在哪里。Loop 决定结果不合格之后系统怎么继续——是重试、降级、升级给人还是直接停。Graph 决定当前节点完成后哪些组件可以接着跑——分支、并行、审批、恢复路径都归它管。为什么现在必须把这三层拆开看因为一个原始语言模型本身做不了这些事跨会话保存项目状态、访问文件和数据库、调用外部 API、运行测试并读取结果、控制权限和成本、任务失败后恢复、等待人工审批、记录完整执行轨迹。这些能力全部来自模型外部的工程系统而不是模型参数本身。当你分不清问题出在哪一层就会拿 Graph 去补 Harness 的坑或者用无限重试冒充 Loop最后预算烧完了系统还是不稳定。这篇文章面向需要把多个工具接入 AI 能力的开发者我会给出可复制的 settings.json 和 config.toml 骨架配合 CC Switch、Cline 的配置示例并用统一的 Key 和 API 通道完成一次端到端验证。目标很明确让你能区分三层职责在系统出错时改对那一层。2. 用 TaoToken 统一 Key 打通三层配置入口在动手写配置之前先把 Key 和 API 通道这件事解决掉。三层架构里最容易乱的地方就是每个工具各配一套 Key、各走一条通道最后排查问题时根本不知道是 Harness 的工具调用失败还是 Loop 的重试逻辑把错误吞了还是 Graph 的路由条件写错了。我的做法是用一个统一的 API 通道来收敛所有工具的接入点。TaoToken 的 API 地址是 https://taotoken.net/api官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。你可以在控制台里生成一个 Key然后让 CC Switch、Cline 这些工具都指向同一个 base_url。这样做的好处是Harness 层的工具调用日志、Loop 层的重试记录、Graph 层的节点流转全部走同一条通道出问题时能一眼看出是哪一层在报错。具体操作上先到控制台的 API Keys 页面创建一个 Key记下它以 sk- 开头的完整字符串。然后确认你的接入文档里 base_url 填的是 https://taotoken.net/api不要多加路径后缀。这一步看起来简单但我见过太多人因为 base_url 多写了一个 /v1 导致 404然后花半小时怀疑是模型不支持工具调用。统一 Key 之后三层架构的调试逻辑就清晰了Harness 层的问题表现为工具调用参数错误或权限拒绝Loop 层的问题表现为重试次数异常或反馈信息丢失Graph 层的问题表现为节点路由到了不该去的地方。如果 Key 和通道是统一的你就能排除掉「是不是这个工具的 Key 过期了」这类干扰项直接定位到真正的架构问题。3. 可复制的 settings.json 与 config.toml 骨架现在进入配置环节。我会给出两个骨架文件分别对应不同的工具接入方式。你不需要照抄全部字段重点是理解每个字段属于哪一层。3.1 settings.jsonHarness 层的工具与权限声明这个文件主要描述 Harness 层的能力边界——模型能用哪些工具、工作区在哪里、权限怎么控制。{ harness: { workspace: ./agent-workspace, tools: [ { name: read_file, enabled: true, params: { path: string } }, { name: write_file, enabled: true, params: { path: string, content: string }, permission: confirm }, { name: run_shell, enabled: true, params: { command: string }, permission: deny, allowlist: [npm test, pytest] } ], state: { persist: true, checkpoint_dir: ./agent-workspace/.checkpoints } }, loop: { max_retries: 3, evidence_required: true, stop_conditions: [success, max_retries, timeout], timeout_seconds: 120 }, graph: { nodes: [research, verify, write, approve], edges: [ { from: research, to: verify }, { from: verify, to: write, condition: passed }, { from: verify, to: research, condition: failed }, { from: write, to: approve } ] } }注意看 harness 里的 tools 数组每个工具都有明确的 params 声明和 permission 字段。这就是 Harness Engineering 的核心——工具职责单一、参数明确、权限最小化。run_shell 我设成了 deny 加 allowlist只允许跑测试命令这是防止 Agent 在生产环境乱执行的关键。loop 部分只做一件事定义重试上限和停止条件。max_retries 设 3 是因为每轮重试都增加成本和延迟只有当失败成本高于验证成本时增加 Loop 才值得。evidence_required 设为 true 表示每轮必须拿到新证据才能继续不允许围绕信心循环。graph 部分把节点和边显式写出来。verify 节点失败后回到 research这就是一个有限循环的出口设计。approve 节点是人工审批步骤属于 Graph 层的职责不是 Loop 能替代的。3.2 config.toml接入通道与模型参数这个文件管的是接入层——base_url、Key、模型名、超时这些。[provider] base_url https://taotoken.net/api api_key sk-your-key-here model claude-sonnet-4-20250514 timeout_seconds 60 [provider.retry] max_attempts 2 backoff_seconds 1.5 [harness] workspace ./agent-workspace log_level info trace_enabled true [loop] default_max_retries 3 escalate_on [permission_denied, timeout] [graph] checkpoint_on [verify, approve]provider 段里的 base_url 填 https://taotoken.net/apiapi_key 填你在控制台生成的 Key。trace_enabled 打开后Harness 层会记录每次工具调用的完整轨迹这对排查「到底是工具没调对还是模型没选对动作」非常关键。loop 段的 escalate_on 定义了哪些错误直接升级给人不走重试。permission_denied 和 timeout 都属于重试也没用的类型早点交给人比烧预算划算。graph 段的 checkpoint_on 指定在哪些节点保存检查点。verify 和 approve 是两个关键决策点中断后从这里恢复最省事。3.3 CC Switch 与 Cline 的接入示例如果你用 CC Switch 管理多个编码工具可以在它的配置里把 provider 指向同一个 base_url。Cline 的配置类似在设置里找到 API Provider选 Custom然后填{ apiProvider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-your-key-here, model: claude-sonnet-4-20250514 }这里有个坑要注意Cline 的 baseUrl 不要带尾部斜杠也不要自己加 /v1。接入文档里写的是什么就填什么。我试过在 baseUrl 后面加 /v1结果工具调用全部返回 404排查了半天才发现是路径拼接问题。4. 端到端验证一次请求跑通三层配置写完之后必须做一次端到端验证确认三层都能正常工作。我建议用一个最小任务来跑让 Agent 读取一个文件、修改内容、运行测试、根据测试结果决定是否重试。4.1 验证 Harness 层工具调用是否正常先发一个最简单的请求只调用 read_file 工具curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-your-key-here \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 1024, messages: [ { role: user, content: 读取 ./agent-workspace/test.txt 的内容并返回 } ], tools: [ { name: read_file, description: 读取指定路径的文件, input_schema: { type: object, properties: { path: { type: string } }, required: [path] } } ] }如果返回的 content 里包含 tool_use 块并且 input 里的 path 是 ./agent-workspace/test.txt说明 Harness 层的工具声明和调用链路是通的。如果返回的是纯文本而没有 tool_use检查 tools 数组的格式是否正确以及模型是否支持工具调用。4.2 验证 Loop 层重试与停止条件Loop 层的验证需要构造一个会失败的场景。比如让 Agent 运行一个必然失败的测试命令观察它是否按 max_retries 重试以及重试时是否带上了上一轮的错误信息。curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-your-key-here \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 1024, messages: [ { role: user, content: 运行 pytest 并告诉我结果。如果失败分析原因并重试最多重试 2 次。 } ], tools: [ { name: run_shell, description: 运行 shell 命令, input_schema: { type: object, properties: { command: { type: string } }, required: [command] } } ] }观察返回的 tool_use 块里 command 字段的值。第一轮应该是 pytest如果测试失败第二轮应该带上错误信息或者调整后的命令。如果它只是重复跑同一个命令而不带任何新证据说明你的 Loop 设计有问题——不要围绕信心循环要围绕证据循环。4.3 验证 Graph 层节点路由与检查点Graph 层的验证需要多节点配合。你可以用两个请求模拟第一个请求让 Agent 做研究并输出结论第二个请求根据结论决定是继续写作还是返回研究。curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-your-key-here \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 2048, messages: [ { role: user, content: 研究主题AI Agent 三层架构。输出三个关键发现并标注每个发现的置信度。如果置信度低于 0.7标记为需要复核。 } ] }拿到返回后检查是否有标记为需要复核的发现。如果有下一个请求应该路由回研究节点而不是直接进入写作节点。这就是 Graph 层的路由条件在起作用。如果你把所有逻辑都塞进一个 prompt 里让模型自己判断那就没有 Graph只有一团临时代码。5. 本篇常见错排查配置跑不通的时候按下面的顺序排查能省很多时间。404 或 401 错误先检查 base_url 是不是 https://taotoken.net/api不要加 /v1 后缀也不要去掉协议头。401 通常是 Key 没填对或者 Key 被禁用到控制台的 API Keys 页面确认一下。工具调用返回空 input检查 tools 数组里的 input_schema 是否符合 JSON Schema 规范。required 字段必须和 properties 里的 key 对应。我见过有人把 required 写成 required: true结果模型不知道该填什么参数。Loop 无限重试检查 max_retries 是否设置以及 stop_conditions 里有没有包含 max_retries。如果模型每轮都返回同样的错误而不带新证据说明你的反馈机制没设计好——每轮重试必须获得新信息否则就是费用泄漏。Graph 节点路由错误检查 edges 里的 condition 字段是否和实际返回的状态匹配。condition 是字符串比较大小写敏感。如果 verify 节点返回的是 Passed 而你的 condition 写的是 passed路由就会走错分支。跨会话状态丢失检查 harness.state.persist 是否为 truecheckpoint_dir 路径是否存在且可写。如果 checkpoint 目录不存在有些工具会静默失败而不是报错。权限拒绝但不知道拒了什么打开 trace_enabled查看 Harness 层的调用日志。日志里会记录每次工具调用的参数和权限判定结果。如果 run_shell 被 deny 了日志里会显示是 allowlist 没匹配上还是 permission 字段设成了 deny。6. 三层各归其位统一通道收口回到最开始的问题Harness、Loop、Graph 到底怎么区分我的经验是系统出错时先问三个问题——它缺少正确的工作环境吗它缺少基于证据的反馈循环吗它的执行路径是否需要显式控制找到拥有问题的那一层再动手改。Harness 层的问题表现为工具调不动、状态存不住、权限控不住。Loop 层的问题表现为重试不带新证据、停止条件不明确、失败后不知道升级给人。Graph 层的问题表现为分支藏在临时代码里、并行任务互相踩、审批步骤被跳过。三层都配好之后用统一的 Key 和 API 通道收口。所有工具走 https://taotoken.net/apiKey 在控制台统一管理接入文档里确认 base_url 和参数格式。这样排查问题时你能快速排除接入层的干扰直接定位到架构层。如果你主要在做长期编码任务或者 Agent 开发建议把 Coding Plan 也配起来让编码工具和 Agent 走同一条通道。验证模型能力的时候可以直接在模型对话里发请求确认模型本身是否支持工具调用和多轮反馈。需要管理多个 Key 或者查看调用记录到控制台的 API Keys 页面操作就行。架构复杂度应该来自已经观察到的真实需求而不是对「高级 Agent」的想象。先把 Harness 做可靠再为高价值失败加 Loop最后把稳定的复杂路径固化成 Graph。这个顺序别搞反。 Agent Harness、Loop 与 Graph 三层架构辨析：用 TaoToken 统一 Key 跑通配置骨架
1. 三层架构到底在吵什么Harness、Loop、Graph 的边界Agent Harness、Loop、Graph 这三个词经常出现在同一场技术讨论里很多人把它们当成近义词换着用。但如果你正在做多工具接入 AI 能力的开发混用这三层会直接导致架构决策跑偏。我用一句话帮你先记住Harness 管环境Loop 管反馈Graph 管流程。它们相互嵌套但不能彼此替代。具体来说Agent Harness 是包裹在模型外部的运行系统决定模型在什么环境里工作——有没有文件读写、能不能调 Shell、状态能不能跨会话保存、权限边界在哪里。Loop 决定结果不合格之后系统怎么继续——是重试、降级、升级给人还是直接停。Graph 决定当前节点完成后哪些组件可以接着跑——分支、并行、审批、恢复路径都归它管。为什么现在必须把这三层拆开看因为一个原始语言模型本身做不了这些事跨会话保存项目状态、访问文件和数据库、调用外部 API、运行测试并读取结果、控制权限和成本、任务失败后恢复、等待人工审批、记录完整执行轨迹。这些能力全部来自模型外部的工程系统而不是模型参数本身。当你分不清问题出在哪一层就会拿 Graph 去补 Harness 的坑或者用无限重试冒充 Loop最后预算烧完了系统还是不稳定。这篇文章面向需要把多个工具接入 AI 能力的开发者我会给出可复制的 settings.json 和 config.toml 骨架配合 CC Switch、Cline 的配置示例并用统一的 Key 和 API 通道完成一次端到端验证。目标很明确让你能区分三层职责在系统出错时改对那一层。2. 用 TaoToken 统一 Key 打通三层配置入口在动手写配置之前先把 Key 和 API 通道这件事解决掉。三层架构里最容易乱的地方就是每个工具各配一套 Key、各走一条通道最后排查问题时根本不知道是 Harness 的工具调用失败还是 Loop 的重试逻辑把错误吞了还是 Graph 的路由条件写错了。我的做法是用一个统一的 API 通道来收敛所有工具的接入点。TaoToken 的 API 地址是 https://taotoken.net/api官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。你可以在控制台里生成一个 Key然后让 CC Switch、Cline 这些工具都指向同一个 base_url。这样做的好处是Harness 层的工具调用日志、Loop 层的重试记录、Graph 层的节点流转全部走同一条通道出问题时能一眼看出是哪一层在报错。具体操作上先到控制台的 API Keys 页面创建一个 Key记下它以 sk- 开头的完整字符串。然后确认你的接入文档里 base_url 填的是 https://taotoken.net/api不要多加路径后缀。这一步看起来简单但我见过太多人因为 base_url 多写了一个 /v1 导致 404然后花半小时怀疑是模型不支持工具调用。统一 Key 之后三层架构的调试逻辑就清晰了Harness 层的问题表现为工具调用参数错误或权限拒绝Loop 层的问题表现为重试次数异常或反馈信息丢失Graph 层的问题表现为节点路由到了不该去的地方。如果 Key 和通道是统一的你就能排除掉「是不是这个工具的 Key 过期了」这类干扰项直接定位到真正的架构问题。3. 可复制的 settings.json 与 config.toml 骨架现在进入配置环节。我会给出两个骨架文件分别对应不同的工具接入方式。你不需要照抄全部字段重点是理解每个字段属于哪一层。3.1 settings.jsonHarness 层的工具与权限声明这个文件主要描述 Harness 层的能力边界——模型能用哪些工具、工作区在哪里、权限怎么控制。{ harness: { workspace: ./agent-workspace, tools: [ { name: read_file, enabled: true, params: { path: string } }, { name: write_file, enabled: true, params: { path: string, content: string }, permission: confirm }, { name: run_shell, enabled: true, params: { command: string }, permission: deny, allowlist: [npm test, pytest] } ], state: { persist: true, checkpoint_dir: ./agent-workspace/.checkpoints } }, loop: { max_retries: 3, evidence_required: true, stop_conditions: [success, max_retries, timeout], timeout_seconds: 120 }, graph: { nodes: [research, verify, write, approve], edges: [ { from: research, to: verify }, { from: verify, to: write, condition: passed }, { from: verify, to: research, condition: failed }, { from: write, to: approve } ] } }注意看 harness 里的 tools 数组每个工具都有明确的 params 声明和 permission 字段。这就是 Harness Engineering 的核心——工具职责单一、参数明确、权限最小化。run_shell 我设成了 deny 加 allowlist只允许跑测试命令这是防止 Agent 在生产环境乱执行的关键。loop 部分只做一件事定义重试上限和停止条件。max_retries 设 3 是因为每轮重试都增加成本和延迟只有当失败成本高于验证成本时增加 Loop 才值得。evidence_required 设为 true 表示每轮必须拿到新证据才能继续不允许围绕信心循环。graph 部分把节点和边显式写出来。verify 节点失败后回到 research这就是一个有限循环的出口设计。approve 节点是人工审批步骤属于 Graph 层的职责不是 Loop 能替代的。3.2 config.toml接入通道与模型参数这个文件管的是接入层——base_url、Key、模型名、超时这些。[provider] base_url https://taotoken.net/api api_key sk-your-key-here model claude-sonnet-4-20250514 timeout_seconds 60 [provider.retry] max_attempts 2 backoff_seconds 1.5 [harness] workspace ./agent-workspace log_level info trace_enabled true [loop] default_max_retries 3 escalate_on [permission_denied, timeout] [graph] checkpoint_on [verify, approve]provider 段里的 base_url 填 https://taotoken.net/apiapi_key 填你在控制台生成的 Key。trace_enabled 打开后Harness 层会记录每次工具调用的完整轨迹这对排查「到底是工具没调对还是模型没选对动作」非常关键。loop 段的 escalate_on 定义了哪些错误直接升级给人不走重试。permission_denied 和 timeout 都属于重试也没用的类型早点交给人比烧预算划算。graph 段的 checkpoint_on 指定在哪些节点保存检查点。verify 和 approve 是两个关键决策点中断后从这里恢复最省事。3.3 CC Switch 与 Cline 的接入示例如果你用 CC Switch 管理多个编码工具可以在它的配置里把 provider 指向同一个 base_url。Cline 的配置类似在设置里找到 API Provider选 Custom然后填{ apiProvider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-your-key-here, model: claude-sonnet-4-20250514 }这里有个坑要注意Cline 的 baseUrl 不要带尾部斜杠也不要自己加 /v1。接入文档里写的是什么就填什么。我试过在 baseUrl 后面加 /v1结果工具调用全部返回 404排查了半天才发现是路径拼接问题。4. 端到端验证一次请求跑通三层配置写完之后必须做一次端到端验证确认三层都能正常工作。我建议用一个最小任务来跑让 Agent 读取一个文件、修改内容、运行测试、根据测试结果决定是否重试。4.1 验证 Harness 层工具调用是否正常先发一个最简单的请求只调用 read_file 工具curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-your-key-here \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 1024, messages: [ { role: user, content: 读取 ./agent-workspace/test.txt 的内容并返回 } ], tools: [ { name: read_file, description: 读取指定路径的文件, input_schema: { type: object, properties: { path: { type: string } }, required: [path] } } ] }如果返回的 content 里包含 tool_use 块并且 input 里的 path 是 ./agent-workspace/test.txt说明 Harness 层的工具声明和调用链路是通的。如果返回的是纯文本而没有 tool_use检查 tools 数组的格式是否正确以及模型是否支持工具调用。4.2 验证 Loop 层重试与停止条件Loop 层的验证需要构造一个会失败的场景。比如让 Agent 运行一个必然失败的测试命令观察它是否按 max_retries 重试以及重试时是否带上了上一轮的错误信息。curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-your-key-here \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 1024, messages: [ { role: user, content: 运行 pytest 并告诉我结果。如果失败分析原因并重试最多重试 2 次。 } ], tools: [ { name: run_shell, description: 运行 shell 命令, input_schema: { type: object, properties: { command: { type: string } }, required: [command] } } ] }观察返回的 tool_use 块里 command 字段的值。第一轮应该是 pytest如果测试失败第二轮应该带上错误信息或者调整后的命令。如果它只是重复跑同一个命令而不带任何新证据说明你的 Loop 设计有问题——不要围绕信心循环要围绕证据循环。4.3 验证 Graph 层节点路由与检查点Graph 层的验证需要多节点配合。你可以用两个请求模拟第一个请求让 Agent 做研究并输出结论第二个请求根据结论决定是继续写作还是返回研究。curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-your-key-here \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 2048, messages: [ { role: user, content: 研究主题AI Agent 三层架构。输出三个关键发现并标注每个发现的置信度。如果置信度低于 0.7标记为需要复核。 } ] }拿到返回后检查是否有标记为需要复核的发现。如果有下一个请求应该路由回研究节点而不是直接进入写作节点。这就是 Graph 层的路由条件在起作用。如果你把所有逻辑都塞进一个 prompt 里让模型自己判断那就没有 Graph只有一团临时代码。5. 本篇常见错排查配置跑不通的时候按下面的顺序排查能省很多时间。404 或 401 错误先检查 base_url 是不是 https://taotoken.net/api不要加 /v1 后缀也不要去掉协议头。401 通常是 Key 没填对或者 Key 被禁用到控制台的 API Keys 页面确认一下。工具调用返回空 input检查 tools 数组里的 input_schema 是否符合 JSON Schema 规范。required 字段必须和 properties 里的 key 对应。我见过有人把 required 写成 required: true结果模型不知道该填什么参数。Loop 无限重试检查 max_retries 是否设置以及 stop_conditions 里有没有包含 max_retries。如果模型每轮都返回同样的错误而不带新证据说明你的反馈机制没设计好——每轮重试必须获得新信息否则就是费用泄漏。Graph 节点路由错误检查 edges 里的 condition 字段是否和实际返回的状态匹配。condition 是字符串比较大小写敏感。如果 verify 节点返回的是 Passed 而你的 condition 写的是 passed路由就会走错分支。跨会话状态丢失检查 harness.state.persist 是否为 truecheckpoint_dir 路径是否存在且可写。如果 checkpoint 目录不存在有些工具会静默失败而不是报错。权限拒绝但不知道拒了什么打开 trace_enabled查看 Harness 层的调用日志。日志里会记录每次工具调用的参数和权限判定结果。如果 run_shell 被 deny 了日志里会显示是 allowlist 没匹配上还是 permission 字段设成了 deny。6. 三层各归其位统一通道收口回到最开始的问题Harness、Loop、Graph 到底怎么区分我的经验是系统出错时先问三个问题——它缺少正确的工作环境吗它缺少基于证据的反馈循环吗它的执行路径是否需要显式控制找到拥有问题的那一层再动手改。Harness 层的问题表现为工具调不动、状态存不住、权限控不住。Loop 层的问题表现为重试不带新证据、停止条件不明确、失败后不知道升级给人。Graph 层的问题表现为分支藏在临时代码里、并行任务互相踩、审批步骤被跳过。三层都配好之后用统一的 Key 和 API 通道收口。所有工具走 https://taotoken.net/apiKey 在控制台统一管理接入文档里确认 base_url 和参数格式。这样排查问题时你能快速排除接入层的干扰直接定位到架构层。如果你主要在做长期编码任务或者 Agent 开发建议把 Coding Plan 也配起来让编码工具和 Agent 走同一条通道。验证模型能力的时候可以直接在模型对话里发请求确认模型本身是否支持工具调用和多轮反馈。需要管理多个 Key 或者查看调用记录到控制台的 API Keys 页面操作就行。架构复杂度应该来自已经观察到的真实需求而不是对「高级 Agent」的想象。先把 Harness 做可靠再为高价值失败加 Loop最后把稳定的复杂路径固化成 Graph。这个顺序别搞反。