企业官网建设流程全解析

1. 从“单打独斗”到“团队协作”：为什么需要子 Agent

如果你已经跟着前面的章节，把豆包 Agent Harness 的基础玩法摸了个遍，可能会发现一个瓶颈：一个 Agent 的能力再强，它终究是“一个人”。当任务变得复杂，需要同时处理代码生成、文档查询、数据分析、文件操作等多个环节时，让一个 Agent 来回切换角色、调用不同工具，不仅效率低下，还容易出错，就像让一个程序员同时写前端、后端、运维脚本和画 UI 原型图一样，结果往往是哪头都顾不上。

这就是“子 Agent”概念登场的时候。你可以把它理解为一种“团队化”或“模块化”的 Agent 构建思想。核心 Agent（我们称之为“主 Agent”或“协调者”）不再事必躬亲，而是根据任务需求，动态地“召唤”或“委派”给更专业的“子 Agent”去执行特定任务。主 Agent 负责理解用户意图、拆解任务、协调流程并汇总结果，而子 Agent 们则像一个个技能专精的专家，各司其职。

举个例子，你想开发一个“智能数据分析助手”。一个粗糙的单体 Agent 设计可能是：它需要内置 SQL 查询、Python 数据处理、图表生成、报告撰写等多种能力。这不仅让 Agent 的提示词（Prompt）变得无比臃肿，而且在执行一个“分析上周销售数据并生成可视化报告”的任务时，它需要在内部进行复杂的逻辑跳转。

而采用子 Agent 架构，你可以这样设计：

• 主 Agent（项目经理）：接收用户指令“分析上周销售数据并生成报告”。它理解任务后，将其拆解为：1. 查询数据；2. 处理分析；3. 生成图表；4. 撰写报告。
• 子 Agent A（数据库专家）：专门负责编写和验证 SQL 查询语句，从数据库安全地取出原始数据。
• 子 Agent B（数据分析师）：接收原始数据，使用 Pandas 进行清洗、聚合、计算关键指标（如环比、同比增长）。
• 子 Agent C（可视化工程师）：接收处理好的数据，选择合适的图表类型（折线图、柱状图），调用绘图库生成图片。
• 子 Agent D（文档工程师）：将分析结论、关键指标和生成的图表路径整合，撰写一份结构清晰、语言通顺的 Markdown 格式报告。

主 Agent 的工作流就变成了清晰的调度：调用 A -> 将结果传给 B -> 将结果传给 C -> 收集 B 和 C 的结果传给 D -> 将 D 的最终报告返回给用户。每个子 Agent 都可以独立优化自己的提示词和工具集，整个系统的可维护性、可扩展性和执行效率都得到了质的提升。这不仅仅是功能的叠加，更是工程范式的升级。

2. 子 Agent 的核心设计模式与通信机制

理解了“为什么”之后，我们来看看在豆包 Agent Harness 的语境下，子 Agent 具体是如何被设计和实现的。这里没有唯一的“标准答案”，但通常围绕几种核心模式和通信机制展开。

2.1 设计模式：三种常见的协作形态

根据子 Agent 的生成方式和生命周期，我们可以归纳出几种典型模式：

模式一：静态注册与委派这是最直观的方式。你在构建主 Agent 时，就预先定义好若干个功能明确的子 Agent（例如SQLAgent,ChartAgent,ReportAgent）。它们作为独立的、配置完整的 Agent 实例存在。主 Agent 的提示词中会明确告知它拥有这些“下属”及其能力。当任务到来时，主 Agent 根据内部逻辑或规则，决定将任务的某个子环节“委派”（Delegate）给对应的子 Agent 执行。子 Agent 执行完毕后，将结果返回给主 Agent。这种模式结构清晰，职责分明，适合工作流固定的场景。

模式二：动态创建与任务特定化在这种模式下，主 Agent 本身并不预先持有具体的子 Agent 实例，而是具备“创建”Agent 的能力。当遇到一个复杂任务时，主 Agent 可能会分析认为：“要完成这个任务，我需要一个擅长处理自然语言指令的 Agent，和一个擅长进行逻辑推理的 Agent”。于是，它可以动态地生成两个新的、任务特定的子 Agent，分别赋予它们针对性的提示词和工具。任务完成后，这些临时子 Agent 可以被销毁。这种模式非常灵活，能够适应未知或多变的任务类型，但对主 Agent 的规划和创建能力要求更高。

模式三：基于路由的智能调度你可以建立一个“Agent 路由层”或“调度中心”。主 Agent 接收任务后，并不直接决定派给谁，而是将任务描述提交给这个“路由 Agent”。路由 Agent 内部维护着一个“技能注册表”，它根据任务描述，智能地匹配最擅长处理此类任务的子 Agent，并将任务转发给它。子 Agent 将结果先返回给路由，再路由给主 Agent 或下一个环节的 Agent。这种模式解耦了任务识别和执行，便于集中管理所有子 Agent 的能力，常用于构建复杂的多 Agent 系统（MAS）。

2.2 通信机制：数据如何在不同 Agent 间流动

无论采用哪种模式，Agent 之间都需要交换信息。豆包 Agent Harness 底层通常通过以下几种方式实现通信：

1. 函数/工具调用（Function/Tool Calling）的延伸这是最常用、最自然的机制。我们可以把“调用子 Agent”本身，设计成主 Agent 的一个特殊“工具”。这个工具的输入是给子 Agent 的指令和上下文，输出是子 Agent 的执行结果。在实现上，这通常意味着：

• 子 Agent 被包装成一个 API 端点或一个可调用的函数。
• 在主 Agent 的工具列表里，添加一个名为delegate_to_sub_agent的工具，其描述为“将特定任务委托给专业的子代理处理”。
• 当主 Agent 决定委派时，它就会“调用”这个工具，传入参数{“sub_agent_name”: “SQLAgent”, “task”: “查询用户表中最近7天的新增用户数”}。
• 后端服务接收到这个调用，找到对应的SQLAgent实例，运行它，并将返回的查询结果作为该工具调用的结果，传回给主 Agent 的对话上下文。

2. 共享上下文/工作空间（Shared Context/Workspace）对于需要紧密协作、频繁传递中间结果的子 Agent 们，可以建立一个共享的“工作区”。这个工作区可以是一个共享的内存数据结构、一个数据库中的特定记录、或者一个临时文件/目录。每个 Agent 都可以读写这个区域。例如，子 Agent A 将清洗好的数据存入共享区的data_cleaned字段，子 Agent B 直接从该字段读取数据进行计算。这种方式减少了频繁的消息传递开销，但需要精心设计数据格式和并发控制，避免冲突。

3. 消息队列（Message Queue）在更分布式、异步的架构中，Agent 之间可以通过消息队列（如 Redis Pub/Sub, RabbitMQ）进行通信。主 Agent 向一个名为task_for_chart_agent的队列发布一条消息。专门监听这个队列的 Chart 子 Agent 消费该消息，执行任务，然后将结果发布到另一个result_for_main_agent队列。这种方式实现了彻底的解耦和异步处理，适合耗时较长或需要负载均衡的任务，但系统复杂度也显著增加。

在豆包 Agent Harness 的当前实践中，基于函数调用的委派模式是最主流、也是最容易上手的方式。它完美地复用 LLM 已有的工具调用能力，将 Agent 间的协作抽象为一次函数执行，概念清晰，实现直接。

3. 实战：构建一个具有子 Agent 的代码审查助手

理论说得再多，不如动手搭一个。我们来设计并实现一个简单的“智能代码审查助手”。它的核心功能是：用户提交一段代码，助手能自动进行多维度审查并生成报告。我们将使用“静态注册与委派”模式。

核心设计：

• 主 Agent (CodeReviewCoordinator)：协调者。负责接收用户代码，分析代码类型（Python/JavaScript/等），并将代码分别派发给三个专项审查子 Agent，最后汇总报告。
• 子 Agent A (SyntaxStyleReviewer)：代码语法与风格审查员。专注于检查语法错误、是否符合 PEP 8（Python）或 ESLint（JS）等基础规范。
• 子 Agent B (SecurityReviewer)：安全审查员。专注于检查常见安全漏洞，如 SQL 注入、命令注入、硬编码密码、不安全的随机数等。
• 子 Agent C (LogicReviewer)：逻辑与最佳实践审查员。专注于检查代码逻辑缺陷、性能问题、潜在的 Bug 以及是否遵循语言的最佳实践。

3.1 定义子 Agent 的工具与提示词

首先，我们需要定义三个子 Agent。这里以 Python 环境为例，使用类似 LangChain 或自定义框架的思维来阐述。每个子 Agent 本质上是一个拥有特定提示词和工具的 LLM 调用实例。

子 Agent A: SyntaxStyleReviewer

• 核心工具：一个本地代码分析工具（例如调用flake8、pylint的命令行接口，或集成black、isort进行格式化建议）。为了简化，我们可以先实现一个模拟工具，它接收代码和语言，返回一个固定的检查结果字符串。
• 提示词关键部分：

  你是一个专注于代码语法和风格的审查专家。你的唯一任务是检查给定代码是否存在语法错误、编码风格是否符合通用规范（如 PEP 8 for Python, Airbnb Style Guide for JavaScript）。请直接、严格地列出所有发现的问题，并为每个问题提供具体的行号和修改建议。如果代码看起来良好，请输出“未发现语法和风格问题”。

子 Agent B: SecurityReviewer

• 核心工具：可以集成开源安全扫描工具（如banditfor Python,npm auditfor JS）的调用，或者基于规则库进行模式匹配。
• 提示词关键部分：

  你是一个网络安全专家，负责代码安全审计。你的任务是识别代码中的潜在安全漏洞。请重点关注：SQL 注入、命令注入、路径遍历、硬编码密钥、不安全的反序列化、弱随机数生成器等。对每个潜在漏洞，说明其风险等级（高/中/低）、位置和修复方案。

子 Agent C: LogicReviewer

• 核心工具：这个 Agent 更依赖 LLM 本身的逻辑分析和代码理解能力。也可以为其提供“单元测试生成”工具，通过尝试生成测试来反推逻辑缺陷。
• 提示词关键部分：

  你是一个经验丰富的软件工程师，擅长发现代码中的逻辑错误、性能瓶颈和设计缺陷。请分析代码的业务逻辑：是否存在无限循环、边界条件处理不当、资源未释放、算法效率低下、错误处理缺失、代码重复等问题？请提供具体的优化建议。

3.2 实现主 Agent 的委派逻辑

主 Agent 的提示词需要清晰地说明它的角色和可用的“委派工具”。

主 Agent (CodeReviewCoordinator) 提示词框架：

你是一个智能代码审查协调员。用户会给你一段代码。你需要做以下工作：

1. 初步判断代码的主要编程语言（如 Python, JavaScript, Java 等）。
2. 你将拥有三个专项审查工具，分别对应语法风格、安全、逻辑三个维度。不要尝试自己进行深入审查，你的核心工作是协调。
3. 你的操作步骤必须是： a. 调用review_syntax_style工具，传入代码和语言。 b. 调用review_security工具，传入代码和语言。 c. 调用review_logic工具，传入代码和语言。
4. 收集所有工具的返回结果后，将它们整合成一份最终、完整的代码审查报告。报告应结构清晰，包含概述、分项详情（语法、安全、逻辑）和总结性建议。
5. 如果无法判断语言，或代码过短无需深度审查，请直接给出你的简要分析。

接下来，我们需要在后台实现这三个“工具”。每个工具的实现，本质上就是去调用对应的子 Agent。

# 伪代码示例，展示工具函数的核心逻辑 def review_syntax_style(code: str, language: str) -> str: """ 工具函数：调用语法风格审查子Agent """ # 1. 构造子Agent A (SyntaxStyleReviewer) 的提示词和消息 sub_agent_prompt = f""" [你是SyntaxStyleReviewer，提示词内容...] 请审查以下{language}代码： ``` {code} ``` """ # 2. 调用LLM（例如豆包大模型API），使用子Agent A的专属提示词 # 这里假设有一个 call_llm 函数，它接收消息列表和系统提示 response = call_llm( messages=[{"role": "user", "content": sub_agent_prompt}], system_prompt=SYNTAX_AGENT_SYSTEM_PROMPT # 子Agent A的系统角色设定 ) # 3. 返回子Agent的审查结果 return response def review_security(code: str, language: str) -> str: # 类似地，调用子Agent B (SecurityReviewer) # 可能会结合静态分析工具的结果 sub_agent_prompt = f"""...""" # SecurityReviewer的提示词 response = call_llm(messages=..., system_prompt=SECURITY_AGENT_SYSTEM_PROMPT) return response def review_logic(code: str, language: str) -> str: # 调用子Agent C (LogicReviewer) sub_agent_prompt = f"""...""" # LogicReviewer的提示词 response = call_llm(messages=..., system_prompt=LOGIC_AGENT_SYSTEM_PROMPT) return response

然后，将这三个函数注册为主 Agent 可用的工具。当主 Agent 的 LLM 决定调用review_syntax_style时，后端就会执行对应的函数，从而完成一次对子 Agent 的“委派”。

3.3 运行流程与结果汇总

用户提交一段 Python 代码后，流程如下：

1. 主 Agent 接收到代码，识别为 Python。
2. 主 Agent 的 LLM 根据提示词，依次生成三个工具调用请求（review_syntax_style,review_security,review_logic），每次调用都包含代码和语言参数。
3. 后端依次执行这三个工具函数。每个函数都会去调用其对应的子 Agent（即用特定的系统提示词和用户消息调用大模型）。
4. 三个子 Agent 的审查结果作为工具调用结果，依次返回给主 Agent 的对话上下文。
5. 主 Agent 的 LLM 看到所有工具调用的结果都已返回，便根据提示词的最后一步，生成一份汇总报告。

最终，用户得到的就是一份由三位“专家”共同完成的结构化审查报告，远比单一 Agent 的审查更加全面和深入。

注意：成本与延迟考量。这个例子中，一次审查需要调用4次大模型（1次主Agent + 3次子Agent）。在实际应用中，需要权衡审查质量和成本/延迟。对于简单代码，可能只需要主Agent快速浏览；对于复杂或关键代码，才启用完整的子Agent审查链。这可以通过在主Agent的提示词中加入判断逻辑来实现。

4. 子 Agent 系统的高级议题与避坑指南

当你开始构建包含多个子 Agent 的系统时，会遇到一些更复杂但必须面对的问题。处理好这些问题，你的多 Agent 系统才能稳定、高效。

4.1 会话隔离与上下文管理

这是子 Agent 架构中最容易踩坑的地方之一。每个子 Agent 都应该有自己独立的“会话”或“上下文”吗？还是共享主 Agent 的上下文？

• 独立上下文（推荐用于职责单一的子Agent）：就像我们上面的代码审查例子，每个子 Agent (SyntaxStyleReviewer,SecurityReviewer) 在执行任务时，只接收与本次任务直接相关的输入（代码和语言），而不感知主 Agent 与用户之前的对话历史。这样做的好处是干净、无状态、可复用。子 Agent 不会受到无关对话的干扰，也更容易进行性能优化和缓存。实现上，每次调用都像是开启一个全新的对话。
• 共享/继承上下文：有些场景下，子 Agent 需要了解任务的“来龙去脉”。例如，一个负责“总结会议纪要”的子 Agent，可能需要参考之前讨论中提到的几个关键决策点。这时，主 Agent 在委派时，除了具体指令，还需要传递一部分相关的历史上下文。关键点在于：传递的必须是精炼、相关的上下文，而不是整个对话历史，否则会浪费 Token 并可能引入噪音。通常的做法是，主 Agent 先对历史进行摘要，再将摘要和当前任务一起传给子 Agent。

避坑指南：默认采用独立上下文。仅在子 Agent 的任务理解绝对依赖历史信息时，才谨慎地传递精炼后的上下文。永远不要将冗长的、未经处理的聊天记录直接扔给子 Agent。

4.2 错误处理与故障恢复

在一个多 Agent 工作流中，任何一个子 Agent 失败（如超时、工具调用异常、返回无法解析的结果），都可能导致整个链条中断。

• 超时与重试：为主 Agent 调用子 Agent 的工具设置合理的超时时间。对于可能因网络波动或模型暂时不稳定导致的失败，可以实现简单的重试机制（例如，最多重试2次，每次间隔1秒）。
• 结果验证与降级处理：主 Agent 收到子 Agent 的返回结果后，不应盲目信任。可以设计一些简单的验证规则。例如，对于代码审查子 Agent，如果返回的结果是空字符串或明显无意义的乱码，主 Agent 应能检测到，并触发降级处理——比如记录日志“安全审查子Agent返回异常”，并在最终报告中将安全部分标记为“本次审查未能完成，建议人工复查”。
• 断路与备选方案：对于关键路径上的子 Agent，可以考虑设计备选方案。如果主 Agent 连续多次调用某个子 Agent 都失败，可以暂时“熔断”，在接下来的几次请求中，直接跳过该子 Agent 或使用一个更简单的内置规则来替代其功能，保证主流程不崩溃。

4.3 循环依赖与死锁预防

当 Agent 之间可以互相调用时，就可能出现 A 等 B 的结果，B 又等 A 的结果，导致死锁。在豆包 Agent Harness 的简单委派模型中，通常是由主 Agent 进行单向调度，不容易出现循环。但在更复杂的“自治 Agent”网络（例如，每个 Agent 都可以自主决定调用其他 Agent）中，这个问题必须警惕。

• 设计时规避：明确 Agent 的层级和调用方向，尽量形成有向无环图（DAG）结构，避免双向等待。
• 运行时检测：为每个任务或会话引入一个唯一的session_id和调用深度depth。每次 Agent 调用另一个 Agent 时，深度加1，并将被调用者的 ID 和当前深度记录到会话上下文中。如果检测到某个 Agent 在同一个session_id下被以相同或更深的深度再次调用（即出现了环），则立即终止并返回错误。
• 设置全局超时：为整个多 Agent 任务设置一个总时长限制。超过时限仍未完成，则强制终止所有相关进程，返回超时错误，避免资源被无限占用。

4.4 性能优化：并行化与缓存

串行调用多个子 Agent（如 A -> B -> C）会导致总耗时是各子 Agent 耗时的累加。在很多场景下，子 Agent 之间的任务是可以并行执行的。

• 并行委派：在我们代码审查的例子中，语法审查、安全审查、逻辑审查这三项工作彼此独立，没有先后依赖。主 Agent 完全可以同时发起这三个工具调用。在实现上，这意味着主 Agent 在一次回复中，可以生成多个并行的工具调用请求（在 OpenAI 的 API 中，这体现在parallel_tool_calls特性）。后端需要有能力并发地处理这些调用，然后等待所有结果返回后再汇总。这能大幅缩短整体响应时间。
• 结果缓存：对于一些计算密集型或确定性较高的子 Agent 任务（例如，对同一段代码进行语法检查，结果在短时间内是相同的），可以引入缓存机制。将“代码内容+子Agent标识”作为键，将其审查结果缓存一段时间（如5分钟）。下次遇到相同请求时，直接返回缓存结果，避免重复调用大模型或分析工具，节省成本和时间。

构建子 Agent 系统，从简单的静态委派到复杂的动态调度，是一个逐步深入的过程。它要求开发者不仅熟悉单个 Agent 的构建，更要具备系统设计的思维，考虑模块化、通信、容错和性能。当你成功地将一个笨重的“全能型”Agent 拆解、重构成一个分工明确、协作流畅的“小团队”时，你会真正体会到智能体工程化带来的力量与美感。这不仅仅是功能的实现，更是对复杂问题的一种优雅的架构解决方案。