一、教程目标
本教程旨在帮助开发者、技术负责人及企业用户系统理解并落地一套可复用的主智能体提示词设计方法。通过拆解提示词的组织结构、决策流程、子代理调度策略、输出规范及内部工具调用原则，读者能够构建一个逻辑清晰、可扩展、可维护的主智能体提示词框架，并在企业实际业务中完成从任务理解、计划制定到执行验证的闭环。
完成本教程后，你将能够：
- 明确主智能体的人设、职责边界与目标定义方式；
- 掌握“评估—分类—计划—执行”的四步思考循环；
- 根据任务复杂度合理规划子代理数量与分工；
- 设计标准化的委派指令与输出格式；
- 在提示词中安全、有效地声明和调用企业内部工具；
- 利用并行工具调用提升整体执行效率；
- 理解并落实主智能体提示词中的核心行为规则。
二、适用场景
本教程适用于以下典型场景：
- 企业希望将内部知识库、工单系统、审批流、数据查询等能力通过智能体统一编排；
- 开发团队需要设计一个可处理多类型任务的主调度智能体，负责任务分派与结果汇总；
- 技术负责人希望规范智能体行为，确保输出格式一致、执行路径可追踪；
- 需要将多个专用子代理组合为协作体系，以应对复杂业务流程；
- 企业用户希望了解在提示词层面如何安全地声明工具调用能力，避免工具误用或越权。
三、前置准备
在开始设计主智能体提示词之前，建议具备以下基础：
- 基础概念理解：了解智能体、提示词、工具调用、子代理委派等基本概念，理解主智能体与子代理之间的调度关系。
- 任务场景梳理：明确主智能体需要处理的核心任务类型，例如信息检索、数据汇总、流程审批、内容生成、故障排查等。
- 工具清单整理：提前梳理企业内部可供调用的工具或接口清单，包括工具名称、用途、输入输出格式、权限要求及调用限制。
- 输出规范定义：确定最终答案应遵循的格式要求，例如是否包含总结、分点、表格、代码块、引用来源等结构。
- 运行环境确认：确认提示词将运行在何种对话或编排环境中，以及该环境对工具调用、并行请求和上下文长度的支持能力。
注意：本文不涉及任何具体云厂商或品牌工具，仅以通用概念描述工具调用与编排逻辑。
四、主智能体提示词的核心结构
一个完整的主智能体提示词通常由以下八大模块构成：
- 人设与目标
- 研究过程与思考循环
- 子代理数量与兵力部署
- 委派指令与任务分配
- 答案格式规范
- 内部工具使用说明
- 并行工具调用策略
- 核心行为规则
下面逐一展开说明。
4.1 人设与目标定义
人设与目标是主智能体提示词的开篇部分，直接决定智能体的行为基调与优先级。这一模块应回答三个问题：我是谁、我要做什么、我服务谁。
写作建议如下：
- 角色定位：明确主智能体的身份，例如“你是一个企业级任务调度主智能体，负责理解用户需求并将任务分解给合适的子代理”。角色定位越清晰，后续行为边界越容易控制。
- 服务对象：说明主要服务对象是开发者、运维人员、业务分析师还是普通企业用户。不同对象对答案的颗粒度、技术深度和语气要求不同。
- 核心目标：用一至两句话概括主智能体的最终目标。例如：“在保证信息准确与格式规范的前提下，以最短路径完成用户任务，并在必要时调用内部工具或委派子代理。”
- 职责边界：明确主智能体“不做什么”。例如不得编造数据、不得绕过审批流、不得调用未授权工具等。边界约束是后续所有行为规则的基础。
示例表述：
你是一个面向企业研发场景的主调度智能体。你的目标是在权限范围内，通过分析任务、制定计划、调用工具与子代理，最终返回结构化、可验证的答案。你服务的主要对象是开发者和技术负责人。未经用户确认，不得执行不可逆操作。
4.2 研究过程：四步思考循环
四步思考循环是主智能体处理任务时的核心决策框架，依次为：评估与分解、查询类别判定、基于分类的计划制定、执行。
步骤一：评估与分解
拿到用户输入后，主智能体首先需要对任务进行整体评估。评估的核心维度包括：
- 任务复杂度：这是一个单步问答，还是多阶段任务？是否需要跨多个数据源或工具？
- 依赖关系：任务是否依赖于前置结果？是否存在并行子任务？
- 数据来源：所需信息来自内部知识库、数据库、API 接口，还是需要人工确认？
- 权限要求：完成任务需要调用哪些工具？是否具备相应权限？
- 输出期望：用户期望的是简短答案、详细报告还是可执行方案？
在评估基础上，主智能体应将大任务拆解为若干可独立执行的子任务。拆解粒度以“每个子任务可由单个子代理或单次工具调用独立完成”为宜。拆解过细会增加调度开销，过粗则可能导致单点执行失败。
步骤二：查询类别判定
在拆解任务后，主智能体需要为每个子任务判定其查询类别。常见的查询类别包括：
- 事实查询：可从知识库或数据库中直接检索到确定答案，无需推理或生成。
- 计算查询：需要基于输入数据进行统计、聚合或数值计算。
- 生成查询：需要生成自然语言内容，如报告、总结、邮件、方案等。
- 对比分析：需要获取多个对象的信息并进行横向比较。
- 诊断排查：需要根据已知现象逐步定位问题根因，可能涉及多轮工具调用。
- 操作执行：需要在受控环境中执行创建、更新、审批等动作，通常需要权限校验与确认。
判定查询类别的目的是为后续计划制定提供依据。不同类别对应不同的执行策略和输出格式。例如，事实查询宜直接返回精确答案并附来源；诊断排查则需要保留中间推理过程与证据链。
步骤三：基于分类的计划制定
根据查询类别，主智能体为每个子任务制定具体执行计划。计划应至少包含以下要素：
- 执行方式：直接回答、调用单个工具、委派子代理，或组合执行；
- 所需输入：执行前需要准备的数据或上下文；
- 预期输出：该步骤完成后应产出的中间结果格式；
- 验证方式：如何判断该步骤成功，例如字段完整、数值合理、来源可追溯；
- 失败兜底：执行失败时的降级策略，例如重试、换用备用数据源或请求人工介入。
对于多步骤任务，计划还应标明步骤间的顺序关系与依赖条件。可以用简单的流程表示，例如：
步骤A（获取用户近30天操作日志）→ 步骤B（按错误码聚合统计）→ 步骤C（根据统计结果生成故障摘要）→ 步骤D（给出排查建议）
步骤四：执行
执行阶段主智能体按照既定计划逐步操作。在执行过程中需要注意：
- 先验证再执行：对于涉及写操作或不可逆操作的步骤，应先确认权限与影响范围；
- 记录中间结果：每个子任务的输出应保留在上下文中，便于后续步骤引用和最终答案溯源；
- 动态调整：如果中间结果与预期不符，应回到评估阶段重新调整计划，而不是机械执行原方案；
- 及时终止：如果发现任务超出权限范围或存在安全风险，应立即停止并向用户说明原因。
4.3 子代理委派与兵力部署
并非所有任务都需要委派子代理。主智能体应根据任务规模、并行度和专业深度决定是否拆分以及拆分数量。
子代理数量法则：
- 单步简单查询：不委派，主智能体直接回答；
- 2～3 个独立子任务：可委派 2～3 个子代理并行处理；
- 4 个以上子任务且彼此独立：建议按“数据获取类”“分析生成类”“校验修正类”分组委派；
- 子任务之间强依赖：不宜并行委派，应串行执行并传递上下文；
- 单一子任务专业度过高：委派一个专用子代理，但需提供明确的输入输出契约。
委派指令设计要点：
每条委派指令应包含以下字段：
- 任务目标：用一句话说明要完成什么；
- 输入数据：明确传给子代理的数据或上下文；
- 输出格式：要求子代理返回的结构，例如 JSON、Markdown 表格或纯文本；
- 约束条件：不得做什么、不得调用哪些工具、不得超过多少返回长度；
- 完成标准：定义“完成”的验收条件。
示例委派指令：
请分析以下 30 条错误日志，按错误码进行聚合统计。只调用日志解析工具，不得访问用户数据。返回 Markdown 表格，包含错误码、出现次数、占比，并在表格后给出出现次数最多的前 3 个错误码的简要分析。
4.4 答案格式规范
统一的输出格式可以降低下游消费者（人类用户或后续处理模块）的理解成本。主智能体提示词中应明确默认输出结构。
一个稳健的默认答案格式如下：
- 结论摘要：用 2～3 句话直接回答用户核心问题；
- 关键信息：分点罗列重要事实、数据或结论，必要时使用表格；
- 过程说明：简述分析过程与决策依据，帮助用户判断可信度；
- 来源与依据：标注信息来自哪个工具、数据源或子代理；
- 后续建议：给出可选的下一步动作或需要用户确认的事项。
对于代码类输出，应使用通用代码块，并注明语言。对于表格类输出，应确保列名清晰、数值单位明确。对于排查类输出，应按照“现象—原因—证据—建议”的结构组织。
4.5 内部工具使用说明
在企业环境中，主智能体通常需要调用内部工具完成数据查询、流程审批或内容生成等操作。提示词中应明确工具使用的规则与方式。
工具声明通用结构：
在提示词中，每个工具可用以下字段描述：
- 工具用途：一句话说明工具的作用；
- 适用场景：什么情况下该调用此工具；
- 输入要求：需要哪些参数、参数类型及必填项；
- 输出说明：返回结果的格式与含义；
- 权限与限制：调用频率、数据范围、是否只读；
- 错误处理：返回异常时的应对策略。
注意：本文不涉及任何具体工具名称或专有接口，仅以通用字段描述。实际落地时，请根据企业自身工具清单替换为真实定义。
工具调用原则：
- 优先使用只读工具获取信息，写操作工具必须经过用户确认；
- 一次任务中尽量合并同类工具调用，减少往返次数；
- 工具返回数据需要校验，不应直接原样输出给用户；
- 工具调用失败时，应尝试记录错误信息并降级处理，而不是静默失败。
4.6 并行工具调用策略
当多个工具调用之间不存在数据依赖时，主智能体应并行发起调用以缩短整体响应时间。并行调用的前提是：调用之间互不依赖，且环境支持并发请求。
常见的可并行场景：
- 同时查询多个独立数据源；
- 同时请求多个子代理分别处理不同维度的子任务；
- 一个任务需要获取日志、指标和配置三类信息，且三者相互独立。
不适宜并行的场景：
- 后一个调用需要前一个调用的返回结果作为输入参数；
- 并发写操作可能导致数据冲突或状态不一致；
- 环境对并发数有限制，盲目并行可能触发限流。
提示词中应明确要求主智能体在执行前先判断依赖关系，并将无依赖的调用放入同一批次并行执行。同时需要规定最大并行数，避免资源争用。
4.7 核心行为规则
主智能体提示词的最后一部分应集中列明不可违反的核心规则。以下为七条通用规则示例，可根据企业实际要求调整：
- 准确优先：不得编造数据、工具返回结果或引用来源。信息不足时明确说明，而不是猜测填充。
- 权限最小化：只调用当前任务确实需要的工具，不越权访问无关数据。
- 过程可追溯：所有关键结论必须能回溯到工具返回、子代理输出或已知事实。
- 格式一致：输出必须遵循答案格式规范，不随意改变结构。
- 失败可见：任何工具调用或子代理执行失败都必须在最终答案中有所体现，不得静默忽略。
- 确认敏感操作：涉及删除、修改、审批、发送等写操作时，必须获得用户明确确认后方可执行。
- 上下文精简：在长任务中定期压缩中间结果，避免上下文溢出，同时保留必要的决策依据。
五、实施步骤示例
下面通过一个完整示例，演示如何将上述模块串成一个可运行的主智能体提示词框架。
场景说明
某企业需要主智能体处理如下用户请求：
“帮我分析过去一周线上服务的错误趋势，按错误类型汇总，并给出前三类错误的处理建议。”
步骤一：评估与分解
主智能体将任务分解为三个子任务：
- 获取过去一周线上服务错误日志；
- 按错误类型进行聚合统计；
- 针对前三类错误生成处理建议。
步骤二：查询类别判定
- 子任务一：事实查询（日志检索）；
- 子任务二：计算查询（聚合统计）；
- 子任务三：生成查询（基于统计结果生成建议）。
步骤三：计划制定
由于子任务二依赖子任务一的结果，子任务三依赖子任务二的结果，因此整体为串行执行：
日志检索 → 聚合统计 → 建议生成
其中，日志检索可以进一步按照服务模块拆分为多个并行查询，前提是不同模块的日志存储相互独立。
步骤四：执行与委派
主智能体先调用日志查询工具获取数据。若日志量较大，可委派两个子代理分别处理“应用错误”和“基础设施错误”两类日志，再汇总统计。统计完成后，主智能体根据结果自行生成建议，或委派擅长故障分析的子代理给出初步建议，最后由主智能体统一审核输出。
结果验证
最终输出应满足：
- 错误类型统计表数据完整，占比合计为 100%；
- 前三类错误均附有简要分析与建议；
- 所有统计结果可追溯到日志查询工具返回；
- 建议部分未提出需要额外权限才能执行的写操作。
六、常见问题与排查
6.1 子代理返回内容与预期格式不符
原因：委派指令中未明确输出格式，或子代理缺乏格式约束能力。
解决思路：在委派指令中加入格式示例，并在主智能体收到返回后做一次格式校验。如不符合，可要求子代理按模板重新返回，或由主智能体进行格式修正。
6.2 并行调用触发限流或超时
原因：环境对并发请求数有限制，或单次请求数据量过大。
解决思路：在提示词中设置最大并行数，并建议将大数据量请求拆分为多个时间窗口或分页查询。并行调用前先评估数据规模。
6.3 工具调用结果不完整或为空
原因：查询条件设置有误、权限不足，或数据尚未同步。
解决思路：先检查查询参数是否合理，再确认工具返回的错误码或提示信息。如为权限问题，应向用户说明缺少哪些权限，并请求授权或调整任务范围。
6.4 上下文过长导致后续步骤丢失早期信息
原因：多步骤任务中保留了过多冗余中间结果。
解决思路：设计中间结果压缩策略。例如每完成一个阶段，只保留摘要、关键统计值和引用来源，删除原始日志明细。提示词中可明确“每个阶段结束后需输出不超过 300 字的结构化摘要”。
七、优化建议
- 提示词分层管理：将人设、规则、工具说明、示例分隔为独立段落，便于后续维护和版本更新。
- 使用示例驱动：在关键模块后附加正反示例，帮助主智能体更稳定地遵循规则。
- 建立工具调用日志：记录每次工具调用的输入、输出与耗时，便于事后审计与性能分析。
- 定期回归测试：构建标准任务集，对提示词修改后的智能体进行回归测试，确保新旧版本行为一致。
- 控制权限粒度：企业场景下建议按角色和场景分配工具权限，避免主智能体持有过多高权限工具，降低误操作风险。
- 持续迭代边界规则：根据实际使用中出现的违规行为，及时补充或调整核心行为规则，使提示词逐步收敛到稳定状态。
八、总结
本文围绕主智能体提示词的系统化设计展开，将提示词拆分为人设目标、四步思考循环、子代理委派、答案格式、内部工具调用、并行执行策略与核心规则等模块，并提供了完整的实施示例与排查思路。
掌握这套方法后，开发者和企业用户可以更高效地构建一个行为可控、输出稳定、工具调用安全的智能体调度层，为后续接入更多企业内部能力奠定基础。下一步可以在此基础上，结合企业自身的工具清单、权限体系和业务场景，逐步细化每个模块的具体内容，并通过实际任务反复验证与迭代优化。