简介：本文面向需要构建复杂任务处理主智能体的开发者与技术负责人，系统拆解主智能体提示词的核心结构，包括人设目标、四步思考循环、子智能体委派、答案格式与内部工具使用规范。通过本文读者可掌握可落地的提示词设计方法，并理解如何在企业环境中安全调用内部系统能力。
本教程旨在帮助开发者、技术负责人以及企业级应用设计者系统性地理解和构建一个主智能体（Main Agent）的提示词体系。完成本教程后，读者应当能够：
本教程不依赖任何特定厂商的专有平台能力，所涉及的智能体设计思路、提示词结构、工具调用规范均为行业通用实践，可在主流技术栈中落地。
主智能体提示词设计适用于以下典型场景：
在上述场景中，主智能体的核心价值不在于“自己完成所有工作”，而在于准确判断任务性质、合理调度资源、规范输出结果。因此，提示词设计的重点也必须围绕这些能力展开。
在开始设计主智能体提示词之前，建议具备以下基础：
| 准备项 | 说明 |
|---|---|
| 基础概念 | 理解智能体（Agent）、提示词（Prompt）、工具调用（Tool Call）、上下文窗口等基本概念 |
| 任务分析能力 | 能够梳理目标业务场景中的常见任务类型与决策分支 |
| 内部工具清单 | 已明确企业内部可供智能体调用的工具列表、能力边界与访问方式 |
| 权限模型 | 了解企业内部工具的认证方式、权限最小化原则与审计要求 |
| 评估机制 | 具备一套可用于评估智能体输出质量的测试问题集 |
如果以上准备项尚未完全具备，建议先完成内部工具盘点与权限梳理，再进行提示词设计。工具清单不清晰会导致智能体在“是否调用工具、调用哪个工具”的决策上出现大量不确定性。
主智能体的提示词通常由七个核心模块组成，每个模块解决一个具体的设计问题。下面逐一展开说明。
人设与目标定义了主智能体“是谁”以及“要完成什么”。这是提示词中最基础也最关键的模块。
一个清晰的人设声明应当包含以下要素：
设计要点：人设描述不宜过于宽泛。过于宽泛的人设会让主智能体在后续决策中缺乏明确的行为约束。建议用一到两句话完成人设定义，用三到五条要点列出职责边界。
示例写法：
你是一个企业研发效能平台的主智能体，负责接收开发者的问题请求，判断问题类型，并将任务分配给具备特定能力的子智能体执行。你本身不直接修改代码或修改生产配置。你的最终输出是一份完整的任务处理报告，包含问题分析、执行过程摘要与结果建议。
四步思考循环是主智能体提示词中最核心的执行逻辑。它要求主智能体在接收到用户请求后，按照“评估与分解—查询类别判定—基于分类的计划制定—执行”四个步骤进行结构化处理。
主智能体首先需要对用户输入进行评估，判断这是一个简单问题还是一个复杂任务。
评估维度建议包含：
提示词中的表述方式：
在收到用户请求后，首先进行评估与分解。判断任务是否可以通过单次回答完成；如果不能，请将任务拆解为彼此独立的子任务，并标记每个子任务的依赖关系与所需能力。
在完成评估之后，主智能体需要判定任务的类型。类型判定决定了后续采取的策略与资源调度方式。
常见的类型划分包括：
设计要点：类型判定不能完全依赖主智能体的自由裁量，应当在提示词中给出明确的判定标准与边界情况处理规则。例如：“如果任务同时包含信息检索与诊断分析，优先按照诊断分析型任务处理，先收集信息再进行分析。”
在确定任务类型之后，主智能体需要制定执行计划。计划的核心内容包括：
计划粒度建议：计划应当细化为可执行步骤，但不宜过度微观。一条经验法则是：每个步骤应当对应一个明确的动作或一个可委派的子任务。如果某个步骤本身仍包含多个决策分支，则应当继续拆分。
提示词中的表述方式：
基于上一步确定的查询类型，制定执行计划。计划中需要明确列出每一步的动作、执行主体（主智能体、子智能体或内部工具）、输入与预期输出。如果计划中包含子智能体，需要说明委派原因。
执行阶段是主智能体按照计划调度资源、调用工具、收集结果的过程。在执行过程中，主智能体需要保持对任务整体进度的感知，并在子智能体返回结果后进行质量检查与结果整合。
执行阶段的关键规则：
主智能体在决定启用多少个子智能体时，需要遵循一定的数量控制原则。数量过少会导致单个子智能体任务过重，影响结果质量；数量过多则会增加协调成本与延迟。
基本原则：
提示词中的表述方式：
仅当主智能体自身能力不足以高效完成子任务时才创建子智能体。单个任务最多创建3个子智能体，每个子智能体只负责一类内聚工作。子智能体之间应尽量保持独立，以便并行执行。
当确定了需要创建的子智能体后，主智能体需要为每个子智能体编写清晰的委派指令。委派指令的质量直接影响子智能体的执行效果。
一条完整的委派指令应包含以下字段：
| 字段 | 说明 |
|---|---|
| 子智能体角色 | 定义该子智能体的身份与专长领域 |
| 任务目标 | 用一句话描述需要完成的具体任务 |
| 输入信息 | 主智能体提供给子智能体的上下文、数据或约束条件 |
| 输出要求 | 子智能体返回结果的格式与内容规范 |
| 边界限制 | 子智能体不可以做什么、不可以访问什么 |
设计要点：委派指令必须具体。模糊的委派指令会导致子智能体自行扩大任务范围，或返回与主智能体预期不一致的结果。建议在提示词模板中固定委派指令的结构，并在主智能体提示词中要求每次委派都必须填写完整字段。
答案格式规范定义了主智能体最终向用户输出结果时的结构。统一的格式规范可以显著提升用户体验，也便于下游系统进行结构化解析。
推荐的答案格式包含以下部分：
提示词中的表述方式：
最终回答必须按照以下结构输出：先给出结论摘要，再进行任务分析，接着说明执行过程与关键步骤，然后呈现详细结果，最后给出风险与建议。如果未使用任何工具或子智能体，则“执行过程”一节可以简化。
企业内部工具的使用是主智能体提示词设计中最需要谨慎处理的部分。企业工具通常涉及权限控制、敏感数据与审计合规要求，因此提示词中必须建立清晰的工具调用边界。
主智能体在调用任何内部工具之前，应当确认以下条件：
提示词中应明确列出工具调用的“允许清单”与“禁止清单”：
对于禁止清单中的工具，主智能体可以生成操作建议或工单草稿，但不得直接触发执行。
当多个工具调用之间没有数据依赖时，主智能体应当并行发起调用，而非串行等待。并行调用可以显著降低整体响应时延。
提示词中的表述方式：
如果多个工具调用之间不存在数据依赖关系，必须并行执行，不得串行逐个调用。如果存在依赖关系，则应等待上游工具返回后再调用下游工具。
主智能体不应当无差别信任工具返回结果。提示词中应要求主智能体对工具返回结果进行基本校验，例如：
校验通过后，主智能体再将结果纳入最终答案。
主智能体提示词的最后一部分通常是核心规则（Guidelines），用于约束主智能体在各类边界情况下的行为。以下给出若干通用规则，可根据实际场景裁剪：
以下给出一个可操作的构建步骤，帮助读者将上述模块落地为一个完整的主智能体提示词。
写下主智能体的角色定位、职责边界与服务对象。建议控制在150字以内。
列出目标场景中可能出现的所有任务类型，并为每种类型定义判定标准。建议使用表格形式整理，例如：
| 任务类型 | 判定标准 | 处理策略 |
|---|---|---|
| 信息检索 | 问题以“查询”“获取”“读取”等动词开头 | 调用检索类工具或子智能体 |
| 诊断分析 | 问题包含“为什么”“原因”“分析”等关键词 | 先收集数据，再调用分析类子智能体 |
| 生成创作 | 问题要求“编写”“生成”“总结” | 调用生成类子智能体或主智能体直接完成 |
将“评估与分解—查询类别判定—计划制定—执行”转化为提示词中的自然语言指令，确保每一步都有明确的输入与输出定义。
确定子智能体的创建条件、数量上限、委派指令模板，以及工具调用的允许清单、禁止清单、并行规则与结果校验规则。
根据业务场景设计输出格式模板，并在提示词中通过示例展示期望的输出结构。
从诚实性、权限、审计、降级、脱敏、一致性、时间感知等维度选择适用的规则，写入提示词末尾。
使用准备好的测试问题集对主智能体进行验证，重点关注：
根据测试结果调整提示词中相关模块的表述与约束强度。
原因：提示词中子智能体创建条件不够明确。
解决思路：在提示词中增加“默认主智能体自行处理”的规则，仅在明确列举的触发条件满足时才允许创建子智能体。
原因：缺少工具返回结果的校验规则。
解决思路：在“执行”步骤中增加结果校验子步骤，要求主智能体检查空值、时间范围、字段匹配度与异常值。
原因：提示词未明确并行调用规则，或主智能体无法正确判断依赖关系。
解决思路：在工具调用规则中明确“无依赖必须并行”，并在计划制定阶段要求主智能体标注每个工具调用之间的依赖关系。
原因：答案格式规范描述不够具体，缺少示例。
解决思路：在提示词中提供一个完整的格式化输出示例，并强调每次输出都必须严格遵循该结构。
原因：缺少失败降级规则。
解决思路：在核心规则中增加失败降级条款，要求主智能体在工具或子智能体不可用时提供降级方案或明确说明影响范围。
从工程化角度，以下建议可以帮助持续提升主智能体的稳定性与可维护性：
本文系统拆解了主智能体提示词的核心设计框架，涵盖人设目标、四步思考循环、子智能体数量法则、委派指令、答案格式、内部工具使用与核心规则七个模块。通过模块化设计与明确的规则约束，主智能体可以在企业场景中稳定地完成复杂任务的理解、拆解、调度与结果输出。
关键要点回顾：
后续可进一步关注多轮对话场景下的状态管理、跨智能体上下文传递以及更细粒度的工具调用权限控制等方向。