Anthropic：谨慎使用子 Agent

来源：微信公众号 HiFox AI · 原文链接

图片展示的是HiFox的标志。标志由左侧的绿色猫头鹰图案和右侧的黑色“hiFox”文字组成，猫头鹰图案简洁，猫眼部分为白色，整体设计风格现代简约。该图片位于文档开头部分，可能是文档的封面或标题页，起到标识文档来源的作用，与文档中介绍HiFox团队的内容相呼应。

子 Agent 越堆越多，什么时候该收回主循环？

在 Applied AI 团队，当我们帮一批企业把 Agent 跑起来之后，得出了一个不太舒服的结论：很多子 Agent，其实没必要存在。

Claude Platform 上不少 Agent 都用了子 Agent——多 Agent 研究系统就是一个。那问题来了：为什么现在反过来劝人少用？子 Agent 到底在哪种场景才划算？并回主循环，质量真的会掉吗？

这篇文章会讲我们对多个企业部署的横向对比，以及把子 Agent 迁回主循环的完整路径。

先给结论：一个配了 Skills 的单 Agent，质量上经常同时打赢「一段提示词包打天下」和「拆成一堆子 Agent」两种方案，单任务成本、延迟往往还更低。有客户把多 Agent 编排改回单循环，端到端快了约 2 倍。

但这不是一篇"反子 Agent"的文章。要改的不是"用不用"，而是"按什么拆"。读到最后你会发现，这件事一半是架构问题，一半是组织问题。

构建 Agent：何时将「子 Agent」折叠进「主 Agent」循环中

在 Claude 平台上构建智能体时，少用子智能体，改用渐进披露的上下文和工具，可以在提升质量的同时降低成本和延迟。下面讲什么时候该做这种迁移，以及怎么迁。

如果你已经在 Claude 平台上构建了包含多个子智能体的智能体，可以用我们的迁移工具包逐一检查，看哪些适合折叠进主智能体循环。它会运行一套引导式工作流，识别你正在使用的模式、评估替代方案，并验证哪种做法效果最好。工具包附带一个演示，可以先在模拟系统上试跑，再用于你自己的智能体。

子智能体——拥有独立上下文窗口、工具和指令、由一个协调者统一调度的智能体——是智能体设计的核心组件。它擅长验证、并行工作以及按模块划分权限。我们自己在 Claude 平台上构建的许多智能体也用到了子智能体，比如我们的多智能体研究系统。

不过，Applied AI 团队最近发现了一种模式：一批企业智能体部署在把路由器、规划器和领域子智能体折叠进主智能体循环之后获益。在我们对多个企业部署的对比中，一个配了 Skills 的单智能体在质量上经常同时胜过「一条提示词包揽一切」的设计和子智能体设计，而且单个任务的成本和延迟往往更低。

比如，有一家公司发现，其面向客户的智能体里的十几个专家子智能体，让始终贴合品牌调性的体验难以维持，还增加了拖累用户体验的延迟。

我们还经常看到遵循一条熟悉路径的智能体方案：先是一个意图分类器，再是一条固定的多步推理流水线、按用户群体划分的桶、各自独立的推荐分支，最上面再叠一个多智能体编排器。

对于这类方案，我们给出的反馈通常是：这些结构里的大部分，做的都是模型已经不再需要别人替它做的事；而一份清晰的系统提示词、4–5 个轻量的数据工具，再加上严格的输出护栏，就能覆盖大部分用例。

图片展示了构建Agent时的两种结构模式。左侧为常见模式，包含5层结构，从上至下依次为请求、多智能体调度器、意图分类器、用户分段桶和推荐分支，最终输出答案。右侧是推荐模式，仅包含1层循环，由请求、模型、4 - 5个轻量数据工具、严格输出护栏组成，模型接受一个清晰系统提示、4 - 5个轻量数据工具及严格输出护栏，最终输出答案。该图与上下文讨论的子智能体使用场景相关，对比说明了不同结构模式。

需要说明的是，子智能体仍有它的用武之地，研究前沿也不例外。以下情况适合使用：

  • 单个智能体循环因上下文膨胀而出现可测量的性能下降；
  • 多个任务需要并行处理，每个任务都要一个全新的上下文窗口，任务完成后即可丢弃；
  • 单个智能体选不准合适的工具，或系统提示词里存在相互冲突的指令。

但我们太常看到企业给每个团队或每种问题类型配一个子智能体，智能体架构于是成了组织架构图的翻版（这正是康威定律在起作用）。

本文结合我们在大型组织中构建智能体积累的最佳实践，讲一讲什么时候应该考虑把子智能体折叠进主智能体循环。

大型组织构建智能体的常见失败模式

公司常常想构建一个把多种产品和能力整合进单一客户界面的智能体。

通常每项能力都由一个独立团队负责，于是公司的做法是先让各团队各自构建自己的智能体，再由一个中央平台团队在上面搭一个编排器。这会形成若干种结构，包括「编排器—子智能体」，或者「单个智能体 + 若干以 MCP 工具形式暴露的特定智能体」。

这看起来是最简单的方案，但会立刻带来以下几方面的复杂性：

  • 上下文管理：你需要决定智能体之间交换哪些上下文，而细节往往就在来回交接中丢失。
  • 子智能体泛滥：每个团队都发布自己的子智能体，公司最终会得到上百个职责重叠的子智能体，既没有强制统一的标准，也没有明确的负责人。
  • 缝合怪提示词：每个团队都往系统提示词里加一句话，结果是规则相互矛盾、没有统一的声音。
  • 未经审核、过度局部化的评估：人人都为子任务加上过度优化的评估，整套评估却没有人负责维护，管理层只能基于被稀释的、过度局部化的分数做决策。
  • 延迟：多智能体架构的复杂性会带来延迟。有一位客户曾把他们的多智能体运行时框架与单智能体循环做对比，后者的运行速度大约是前者的两倍。

使用带渐进披露的智能体循环

上面描述的「编排器—子智能体」设计，对于协调跨团队构建的专家来说是合理方案；但更有效的做法往往是通过 Skills 渐进披露上下文、通过工具搜索渐进披露工具。也就是说，智能体一开始只看到 Skill 和工具的简短描述，只有在真正需要时才完整加载。

这样做有三个理由：

  • 共享上下文能产生更好的答案：对于运行时间较长的智能体，我们希望多个不同任务的上下文都留在主上下文窗口里。一个看过前面每一步结果的智能体能把它们联系起来，从而比子智能体交回的一堆摘要产出更丰富的结果、更好的洞见。这也意味着更少的上下文窗口和更少的有损交接。
  • 渐进披露可以防止上下文膨胀：这项技术让团队能够构建可完成多种任务的单智能体，而不必把所有上下文一次性塞进一条很长的系统提示词。这消除了团队过去把工作拆分到多个子智能体的主要原因。事实上，我们把 Claude Code 面向更先进模型的系统提示词削减了 80% 以上，其中就包括与渐进披露 Skill 和工具相关的削减。
  • 模型本身更强了：从 Opus 4.5 开始，模型在单个循环里能管理的东西就远超大多数团队的预期。在 Opus 5.5 和 Fable 5.1 上，思考过程已经无法关闭；新近的模型还越来越多地边做边叙述进度、检查自己的工作，这让运行时框架里的一些环节变得多余。每一代新模型都让你能把更多决策从运行时框架挪进模型本身。更简单的循环也更容易迁移到下一代模型；在我们帮助客户做迁移的经历中，僵化的多智能体结构常常正是阻碍新模型承担更多工作的东西。

这种单循环设计需要纪律：精心管理的系统提示词、能在正确时机触发的 Skill 和工具描述，以及对上下文窗口、记忆和笔记的审慎处理。本文后续章节会深入讨论迁移与设计方面的考量。

应该由一个中央团队负责端到端质量和系统提示词，在每一个新工具和评估上线前进行审核。让这个中央团队保持小规模，有助于加快迭代，并降低大型组织中的协调成本。

如果你仍要走多智能体路线，就从可行的最简单模式开始（生成器—验证器、编排器—子智能体，或其他）。按上下文划分来有效划定边界：给每个子智能体一块几乎不依赖系统其余部分的工作，让它交回一份紧凑的结果（好的候选包括相互独立的研究路径、接口干净的独立组件，或黑盒验证）。如果按问题类型拆分智能体，它们就会玩起「传话游戏」，信息在一次次交接中来回传递，保真度不断下降。

这张图对比了两种子智能体的划分方式，上方为按问题类型划分的模式，设置了代理1（编写功能）、代理2（编写测试）、代理3（审查代码）三类代理，每类代理之间通过交接传递信息，存在每次交接都会丢失上下文的问题，比如编写测试的代理不清楚功能的实现决策。下方为按上下文划分的模式，将任务交由一个拥有完整上下文的代理（编写功能及测试），并搭配仅运行测试、报告结果而无需实现上下文的验证者，这种划分能避免交接时的信息丢失。

如何把子智能体折叠进主智能体循环

很多团队已经在生产环境中运行着一个编排器和一组专家智能体。下面是我们建议逐步靠近的单循环设计：

  • 一个模型、一个上下文窗口，跑一个开放式的工具调用循环；限制（轮次预算、成本预算、写入门控）由运行时框架设定。
  • 每一轮，模型发出一批工具调用。运行时框架并行执行，把原始结果交回同一个模型，由它决定下一步：再发一批调用、向用户提问，还是直接回答。
  • 循环在模型给出答案或触到预算上限时停止。回答之后还可以选择性地运行一次目标检查或验证器检查。
  • 模型在第一轮就把计划写进上下文，并随着结果到来不断修订。这是与「编排器＋专家智能体」设置相比最主要的变化：写计划的模型和执行计划的是同一个，所以它可以中途改变计划。
  • 上下文仍会被加载，但由智能体自己管理：
  • 不再需要用代码按规则目录改写计划的步骤，因为每一步由模型自己决定。
  • 顺序和领域流程移入Skills。
  • 硬性限制（校验、审批门控）以及其他对话中途才会出现的东西（如记忆查询）移入工具。
  • 代码仍可用于加载那些便宜且几乎总是相关的内容（如实体解析步骤），并在循环调用的工具内部处理纯机械的部分（组装请求载荷、解析流式返回、续接澄清式追问）。

这种单循环设计也有助于许多团队正在追求的终态——一个理解用户高层目标并代表其行事的智能体——因为它把智能体学到的一切都保留在同一个上下文里。

图片展示了从计划到原始结果的流程。左侧“计划”写在上下文里，箭头指向“模型”，再指向“工具调用”，最后到“原始结果”。底部有“修订”标识，箭头从“原始结果”指向“计划”，并标注“写计划和执行的是同一个模型”。该图与上下文紧密相关，直观呈现了智能体循环中模型执行计划并调用工具获取结果，结果又反馈给模型修订计划的流程。

下面这些建议，讲的是一个团队如何分阶段从多智能体系统走向单智能体循环，以及多个团队如何在这一过程中持续为这个智能体做贡献。

任务完成度评估

第一步是创建一套评估集，帮助你判断是否应该把某个子智能体折叠进主智能体循环。我们见过且行之有效的评估结构是：一套由中央团队负责的共享端到端评估集，加上各个 Skill 的负责团队随 Skill 一起交付的小型评估集。哪怕只有 10 个黄金样例，也足够起步。

按评分标准给智能体的最终回复打分，是追踪回答质量的一个好起点。在仍使用编排器的阶段，你还应该追踪路由准确率（它有没有选对子智能体？）；某个子智能体折叠进来之后，则改为检查智能体有没有加载对的 Skill、调用对的工具。随着时间推移逐步向任务完成度评估靠拢是有益的，因为在比较不同架构时，它最重要。

在内部系统难以回放、用户交互难以模拟的环境里，这件事可能很复杂。我们内部行之有效的一个做法，是在重要事件上记录时间戳，之后回放这些事件，作为有针对性的评估来运行。

逐步减少子智能体

向单智能体循环演进的过程，就是把子智能体折叠进工具和 Skills 的过程。具体做法可以是合并领域子智能体、把它们当作工具调用，或者直接用 Skills 和工具替换。

这张图片展示了将子智能体折叠进主智能体循环的三种具体做法，对应向单智能体循环演进的过程。第一种是合并领域子智能体，需组合共享上下文的子智能体以减少数量，图中以主智能体连接多个子智能体后合并为少量子智能体来呈现。第二种是将子智能体当作工具调用，主智能体通过工具调用逐一调用子智能体，子智能体返回结果，主智能体维持对话。第三种是把子智能体折叠进技能和工具，子智能体的提示会转化为技能，其API调用会转化为工具。该图直观呈现了文档中“逐步减少子智能体”部分的具体实施方式。

合并领域智能体

第一次合并之前，先建一个小型端到端评估。然后按共享上下文折叠，从用得最多的子智能体开始。

把那些输出前后相接、操作同一份数据、或经常被一起调用的专家合并起来。比如，如果生产流量中有相当大的一部分是先调用某个专家、紧接着再调用第二个，那这就是一对紧耦合的专家，适合合并成一个领域智能体。

把子智能体当作工具调用

当前文三个条件之一成立、而你决定保留某个子智能体时，让主智能体把它当作工具来调用往往是有效的，这样主智能体就能继续握着与用户的对话。

只有当子智能体需要直接与用户对话时，我们才建议做完全交接、由子智能体接管对话。其余一切都可以用主循环里的 Skill 加工具来实现。

这样你就可以为子智能体定义统一的响应格式，让主智能体用真实数据核对其结论，并精简最后汇总步骤的输入。这是不错的第一步，因为你不需要重写子智能体；在决定把任何子智能体折叠进主智能体之前，它还能先在任务完成度评估上给你一条基线。

不过，一些失败模式仍会存在：

  • 每个专家仍有自己的提示词、上下文、负责团队和评估；
  • 每次调用交回的仍是有损摘要；
  • 每次调用都是一个嵌套的模型循环，会增加延迟。

通过 Skills 和工具把子智能体折叠进主智能体

一次只折叠一个子智能体：把它提示词变成 Skills、API 调用变成 MCP 工具。然后对比有它和没它时的评估表现，再决定保留哪一种。

对比时不要只看最终分数，还要看哪些任务的结果发生了翻转。我们在一个示例客服智能体上测试时，把一个子智能体折叠进另一个之后，延迟降低了，却也弄坏了一个此前一直能通过的流程：主智能体手里握着订单查询工具，于是自顾自作答，没有去问配送专家要送达日期。

图片展示了在客服智能体中，主智能体和配送专家交互的流程。用户询问包裹何时到，主智能体查询订单，配送专家提供送达日期。实际发生时，主智能体查完订单后直接作答，没问配送专家。评估要覆盖的流程中，配送专家需被调用，主智能体询问配送专家后，配送专家给出预计周四送达。该图与上下文紧密相关，直观呈现了主智能体折叠子智能体后出现的流程问题及评估要求。

每次改动之前，都要确保评估集里有任务覆盖生产环境中每一条会一起运行的智能体链路、以及智能体绝不能违反的每一条规则；并且每个任务都要跑不止一次——像这样的故障，两次运行中只出现了一次。

多个团队如何为同一个智能体做贡献

领域推理可以从知识库、Skills 和 MCP 工具中检索得到。各团队可以把自己负责的对象从智能体转为 Skills 和工具，同时由一个小型中央团队继续负责系统提示词和端到端质量。这包括在新的 Skill、工具和评估上线前进行审核。

MCP 工具

当智能体需要执行操作、从系统读取实时数据、或以固定格式返回结果时，工具是合适的选择。迁移期间，你也可以用工具来继续调用尚未折叠的子智能体。我们建议按用户意图组织工具（而不是一个 API 对应一个工具），因为一旦系统提示词里的工具定义超过 30–50 个，工具选择的质量往往就会下降。

使用带延迟加载的工具搜索，尽量少设硬性前置条件，必须存在的就挪进工具里。例如，如果 Y 需要 X 的输出，就让 Y 的工具自己检查 X 的输出在不在，并返回一条模型可以据此行动的指令。按用户区分的权限也是同样的做法：每个工具检查当前调用用户可以看到什么、可以做什么，并返回一段模型能读懂的拒绝说明——这样一个循环就能服务权限不同的用户，不需要为每个权限级别单独做一个智能体。

Skills

当智能体需要知道某个团队是怎么做事的——也就是过去由专家子智能体提示词承载的步骤、规则和判断——Skills 是合适的选择。

面对不断壮大的 Skill 库，我们的做法是把维护工作交还给写 Skill 的人。Claude 可以借助一些能够构建、测试和精简其他 Skills 的 Skills 来承担繁重工作。

为了防止 Skill 泛滥，可以让每个团队的直接负责人（DRI）掌管自己的 Skills，确保它们做工精良、彼此不重复，并随附合适的评估。

  • /skill-creator：用于编写从一开始就结构良好的新 Skill，也能审计已有 Skill，做精简、去重和重组。
  • /skill-doctor：让你看到库里每个 Skill 的成本和实际使用频率，删掉无用的部分。

知识库

知识库适合存放智能体只是偶尔需要的参考资料。事实和参考材料（政策、指标定义、产品规格）可以放在一个由模型调用的搜索或查询工具后面，也可以作为参考文件打包进某个 Skill。尽量避免让代码把这些内容检索出来再贴进提示词。

加速这项工作的工具

我们最近发布了一组 Claude API Skills，能帮忙完成上述大部分工作。我们的迁移工具包把这些 Skills 串成一套引导式工作流，用于评估多智能体系统并将其迁移到单智能体循环。它包含一个演示，可以先试跑，再用于真实系统：

  • /claude-api build-eval：帮助创建由中央团队负责的第一套端到端评估，或各团队随 Skill 交付的小型评估。
  • /claude-api prompt-audit：标记提示词、Skills 和工具描述里那些为旧模型编写的指令，并以 diff 形式给出修改建议。可以在系统提示词上运行它，找出那些为更早的模型添加、如今让智能体变慢或变僵的规则。各团队的 DRI 也可以在自己的 Skill 和工具描述上运行它。
  • /claude-api hillclimb：针对已有评估迭代改进应用。可用于「折叠 vs 保留」的对比（把一个子智能体折叠成 Skill 加工具后，让它迭代优化 Skill 和工具描述，看折叠版能否打平或胜过原子智能体），也可用于优化系统提示词。
  • /claude-api cost-optimize：分析调用去向，并从提示词缓存、裁剪不必要的输入输出 token、调整 effort、更换模型等选项中一次提出一项节省建议，帮助在给定设计上降低成本和延迟。

随着模型演进，我们对如何用好模型的理解、以及围绕最佳实践的指引也在演进。这让任何一种具体架构都不如其背后的原则重要：先测量，一次只改一件事，留下经得起验证的东西。

本文正是其中一例。随着模型越来越强、智能体运行时间越来越长，你的子智能体中会有越来越多可以变成 Skills 和工具。不过你不必一步到位：先建一个小型端到端评估，折叠一个子智能体，如果折叠后的版本得分更差，就把它继续留作子智能体——如此循环往复。

关注 HiFox AI，及时获取 最新 AI 资讯~

欢迎使用 HiFox，一个多人与多 Agent 的协作平台，轻松指挥一堆 Agent 同时并行工作！

HiFox 是什么？

这张图展示了HiFox的核心功能相关内容，左侧文字区域列出了HiFox的核心功能，包括作为AI队友的Agents用于组队协作的Crew小队、统筹任务的任务中心、协助Agent自主工作的Autopilot、精准处理固定流程的Workflow，还有技能与连接器、知识库、Agent相关模板等功能分类；右侧是HiFox的平台界面，呈现全部Agent和小队的列表，包含不同的小队名称与对应的人员头像等内容，整体直观呈现了HiFox的功能架构与平台界面的相关情况。

这张图展示了名为“Agents”的相关内容，左侧界面呈现了“HiFox 团队”的全部Agent列表，每个Agent带有对应头像与标识，均为可交互的团队成员类应用选项。右侧以 bullet point 形式明确了这类Agent的定位与特性：将Agent转化为真正的队友，不再仅作为对话框，而是能像真人一样开展指派任务、跟踪进度等工作；这类Agent已进驻到IM工具与各类任务管理平台，最终沉淀成为组织的核心资产。

这张图片展示了HiFox平台的“BYOA & BYOC”核心功能，分为左右两部分：左侧是选择运行时工具的界面弹窗，列出了 Claude Code、CodeBuddy、Cursor 等多款AI开发相关工具；右侧是该功能的文字说明，明确了两大核心能力：Bring Your Own Agent可自由选择任意AI运行时，支持几乎所有主流开发工具的Runtime，还能自定义Runtime接入；Bring Your Own Computer指Agent可运行在本地机器，支持本地或云服务器的多类型设备，同时后续会支持云机器。该内容匹配文档中“HiFox是什么？”板块的功能介绍，突出平台不被平台锁死、不被Agent框架锁死的特点。

图片展示了HiFox平台中“鞍山开发小队”的界面。左侧为全部Agent和小队列表，右侧是小队详情页面，显示了小队名称、成员、创建时间等信息。下方有“添加新成员”按钮，以及成员列表，每个成员有头像、名称、角色等信息。右侧还列出了小队的协作SOP，包括谁指挥、谁先想、谁执行、谁验收、什么情况需要真人介入确认等内容。该图片与文档中介绍HiFox平台及小队协作的内容相关，直观呈现了小队管理与协作的界面。

这张图片展示了名为HiFox的平台界面，左侧为任务中心的工作看板，呈现了不同分组下的各类任务条目，包含任务名称、进度标识及相关操作选项；右侧则是任务中心的说明内容，明确介绍其核心功能：支持统一任务看板指挥多Agent并行工作，能像分配工作一样向Agent指派任务，将人类与Agent的工作场景整合，遵循“给人安排任务→给Agent安排任务→Agent自主规划任务”的逻辑，还强调让Agent处理长任务，避免人类陷入对话场景，这张图是对该工具功能的直观展示，配合文档介绍其相关属性。

图片展示了HiFox任务处理中Agent提交完成证据的场景。画面左侧是HiFox界面，显示“Open”和“Continue”选项，下方有Agent提交的完成证据，包括代码、图片等。右侧文字说明任务处理中Agent和人类的角色，Agent像人一样被指派任务，按要求完成工作并提交证据，人类指挥和验收结果，指挥一堆Agent并干活，不被对话框锁死，解放生产力，验收Agent完成结果并对结果负责。图片与上下文紧密相关，直观呈现了任务处理流程中的关键环节。

图片展示了HiFox团队在飞书中的沟通及HiFox任务执行情况。左侧是飞书聊天界面，显示了HiFox团队成员的交流，如任务分配、状态更新等。中间部分呈现了HiFox任务执行的界面，有任务描述、执行人、状态等信息。右侧是HiFox任务执行后的反馈界面，显示了任务执行结果及反馈。图片与上下文紧密相关，直观呈现了HiFox团队协作及任务执行的场景，体现了HiFox自动写任务描述、双向同步追踪反馈、上下文不丢失的特点。

图片展示了HiFox与飞书消息双向同步、Agent自动工作、反馈等功能。左侧界面显示HiFox与飞书消息同步，如“HiFox & 飞书消息双向同步”“Agent工作不丢上下文”等字样，还呈现了HiFox与飞书的聊天记录。右侧界面则展示了Agent自动工作、反馈的示例，包括“Agent自动工作、反馈”字样，以及Agent与用户关于“如何使用HiFox”的对话内容。该图片与文档中介绍HiFox功能的内容相契合，直观呈现了其特点。

图片展示了HiFox与传统任务平台双向同步的功能。左侧界面显示了HiFox与Jira、TAPD、Workday等任务管理平台的集成，如Jira、GitLab、飞书等图标及对应平台名称。右侧文字说明HiFox可打通传统任务管理平台，双向同步Jira、TAPD等平台，给人安排任务后可给Agent安排任务，让其自己规划任务，还支持打通IM平台，让Agent入驻已有工作环境，支持Slack、Teams等IM平台。此图与文档中HiFox打通传统任务管理平台的内容相契合。

图片展示了HiFox助手界面。左侧为导航栏，有HiFox助手、HiFox子Agent、HiFox团队等选项。右侧是聊天窗口，上方有“重要”“其他”“稍后”“已读”标签，当前选中“其他”。聊天内容显示了HiFox团队成员的交流记录，如Nicholas讨论了代码、AI等话题，Alan询问了HiFox的运行时等。界面底部有“HiFox助手”“HiFox子Agent”“HiFox团队”选项卡。该图与文档中介绍HiFox助手的内容相关，直观呈现了其界面及部分功能。

图片展示了HiFox客户端界面及Autopilot功能介绍。左侧界面呈现了HiFox客户端的自动化任务列表，如“国际版自动化 - 每周完成任务”“门面入口 - 制作sharex打包”等，每个任务旁有绿色对勾标识。右侧以黑底白字呈现Autopilot功能，包括定时触发、内部事件触发、外部事件触发三种触发方式，如定时任务、业务数据变化、服务器错误日志等触发Agent工作。该图与文档中介绍HiFox客户端及Autopilot功能的内容相呼应。

这张图展示的是Hifox工具的工作流（Workflow）界面，左侧为可视化的工作流设计画布，包含“Create Task”“Assign Agent”“Parse Center”“Comment Result”等节点，节点间通过连线构成任务流转逻辑。右侧是“Workflow”的说明板块，点明该工作流模式适配高度明确、一致性要求高的任务，如财务流程、数据同步，具备Agent管理编排工作流、预设逻辑与人工审批节点等特点，能实现比纯Agent更优的成本与响应速度，还以Posthog捕捉程序报错后依次完成创建任务、指派Agent修复、通知团队的流程作为示例。

**👉 立即体验 Hifox： **https://hifox.com

图片展示的是HiFox内测群的二维码。背景为黑色，二维码外框为绿色，内框为白色。二维码下方有绿色图标，图标内有白色猫头图案。文字部分写着“HiFox内测群”，并提示“扫一扫群二维码加入该群”。该图片位于文档中“👉立即体验Hifox：https://hifox.com”部分之后，是引导用户扫码加入HiFox内测群的视觉元素，与上文体验HiFox的内容相呼应。