AI智能体实践指南：从概念理解到流程搭建

一、教程目标：搭建一个能够完成任务的智能体

本教程将围绕“根据用户需求生成出差方案”这一任务，介绍如何把语言模型、业务工具、执行流程和状态管理组合成一个基础AI智能体。

完成教程后，你应当能够：

• 区分普通问答、固定工作流与智能体的适用边界。
• 理解感知、推理、行动、记忆之间的关系。
• 为智能体定义明确的输入、输出和停止条件。
• 设计工具调用、参数校验与人工确认机制。
• 通过测试用例判断系统是否可靠完成任务。

教程适合具备基础开发知识的开发者，也适合需要评估自动化方案的运维人员、技术负责人和企业用户。

示例以查询、比较和生成建议为主，不直接执行付款或正式预订。这样既能体现智能体的完整工作过程，也能降低原型阶段的业务风险。

二、先理解：AI智能体与普通聊天有什么区别

1. 智能体的核心是围绕目标持续行动

普通问答系统通常在收到问题后生成一段回答。智能体则需要根据任务状态决定下一步：是补充信息、查询外部数据、调用业务工具，还是结束执行。

例如，用户提出：

帮我安排下周去上海出差，停留两天，总预算不超过3000元。

一个可靠的智能体不能立即假定所有条件已经齐全。它需要先确定出发城市、具体日期、会议地点，以及预算包含哪些费用，然后才能查询交通与住宿信息。

这体现了智能体的基本闭环：

接收目标 → 检查信息 → 规划步骤 → 调用工具 → 评估结果 → 继续执行或结束。

智能体不意味着完全无人干预。对付款、删除、发布和修改权限等高影响操作，保留人工审批通常更加合理。

2. 四个核心组成部分

组成部分	主要作用	出差场景中的例子
感知	接收并整理外部信息	读取出差需求、查询结果和费用规定
推理与规划	分解目标并选择下一步	决定先确认日期，再查询交通与住宿
行动	通过受控工具执行操作	查询可选班次、检索住宿、生成行程草稿
记忆与状态	保存执行进度和必要信息	记录已确认日期、预算及工具执行结果

这里的“记忆”不一定需要复杂的存储系统。初期可以只保存当前任务的结构化状态；只有确实需要跨任务复用用户偏好时，再考虑长期存储。

3. 固定流程与智能体并不互相替代

如果处理步骤稳定、业务规则明确，例如根据固定字段生成费用报表，使用确定性工作流通常更容易测试和维护。

如果输入变化较大，需要在多种工具之间动态选择，或者必须根据查询结果调整策略，智能体更有价值。

实际系统常采用混合方式：外层工作流负责权限、预算和审批，内层智能体负责理解需求与提出行动建议。

三、认识常见类型：按任务需求选择架构

智能体可以从不同维度分类，下列类型并不是互斥关系。

1. 按任务执行方式分类

• 反应式智能体：根据当前输入选择动作，适合简单分流、状态判断等任务。
• 目标驱动智能体：围绕最终目标组织多个步骤，适合资料整理、出差规划等任务。
• 规划与执行分离型智能体：先生成计划，再逐步执行并检查结果，适合步骤较多、需要审计的任务。

本教程采用目标驱动方式，并在执行过程中保留简明的计划和状态。

2. 按应用领域分类

常见应用包括：

• 知识辅助：检索授权资料，生成带依据的回答。
• 办公协作：整理文档、生成会议纪要、形成待办清单。
• 开发辅助：理解代码、提出修改建议、生成测试。
• 运维辅助：汇总告警、查询日志、生成故障排查建议。

不同场景的权限要求差异很大。例如，读取日志和重启生产服务不能使用相同的审批策略。

3. 按协作方式分类

单智能体由一个主要决策单元管理任务，结构简单，容易定位问题，适合作为起点。

多智能体将任务分配给不同角色，例如资料收集、方案生成和结果检查。它适合可以明确拆分的复杂任务，但会增加通信成本、结果冲突和状态同步难度。

因此，不要把多智能体当作默认升级路径。只有在单智能体确实出现明确瓶颈时，再评估拆分是否值得。

四、前置准备：先准备能力与边界

1. 语言模型访问能力

选择能够理解任务并输出结构化行动建议的模型。若模型支持工具调用，可按其通用机制接入；若不支持，也可以由应用解析结构化输出，但必须增加严格校验。

模型能够提出调用建议，并不意味着它应当直接持有业务系统的高权限凭据。真正的执行权应由应用控制。

2. 可查询的数据或模拟数据

准备交通、住宿和费用规则的数据来源。原型阶段可以使用固定测试数据，不必立即连接真实交易系统。

使用模拟数据时，必须在输出中明确标记，不能把模拟价格描述为实时可购买价格。接入真实数据后，也应保留查询时间、有效状态和数据来源。

3. 受控执行环境

至少准备：

• 工具清单及其用途说明。
• 输入字段的类型和约束。
• 身份认证与权限检查。
• 日志与任务状态存储。
• 超时、重试和执行步数限制。
• 敏感操作的人工审批入口。

本地原型可以使用简单的状态文件或数据库；生产环境则需要根据并发量、可靠性和审计要求进一步设计。

五、步骤一：把自然语言目标转成任务约束

做什么

将用户的一句话拆解为可检查的字段，区分“必须满足的条件”和“可以权衡的偏好”。

例如：

字段	示例	处理方式
出发地	尚未提供	查询前必须补齐
目的地	上海	必须满足
出行日期	下周，具体日期待确认	必须消除歧义
停留时长	两天	确认是否包含往返当天
总预算	3000元	明确包含哪些费用
住宿偏好	尽量靠近会场	在预算允许时优先满足
操作权限	查询和生成方案	不允许正式预订

为什么这样做

自然语言中的“下周”“尽量便宜”“安排好”都存在解释空间。如果不先确认，智能体即使顺利调用工具，也可能完成一个错误任务。

建议只追问会明显影响结果的缺失信息，避免一次询问大量次要偏好。

明确完成条件

本例可以将完成条件定义为：

生成至少一份符合已确认日期和预算约束的出差方案，列出交通、住宿、费用构成、数据查询时间及待用户确认事项。

若无法找到满足条件的方案，也可以正常结束，但必须说明冲突在哪里，并提供调整建议，而不是虚构可行结果。

六、步骤二：设计最小工具集合

做什么

先为智能体提供少量、职责清晰的工具，例如：

1. 查询交通候选项。
2. 查询住宿候选项。
3. 读取费用规则。
4. 计算费用总额。
5. 保存行程草稿。

这些是示例中的业务能力描述，并非某个产品的真实接口名称。

为什么工具要小而明确

工具范围过大，会使权限边界模糊，也更难判断调用是否合理。例如，“执行任意业务操作”就不适合作为原型工具。

相比之下，“根据城市和日期查询住宿”具有明确的输入、输出和风险范围。

为每项工具建立契约

每项工具都应说明：

• 输入：需要哪些字段，哪些不能为空。
• 约束：日期、城市和金额是否合法。
• 输出：成功时返回什么，失败时如何表示。
• 副作用：是否会修改外部状态。
• 权限：什么身份可以调用。
• 执行控制：超时和重试策略是什么。

查询结果最好携带查询时间、计价单位和费用口径。只有金额而没有“每晚”“每人”或“是否含税”等信息，容易造成后续计算错误。

七、步骤三：建立规划、执行与检查闭环

1. 先生成可检查的简明计划

在必填信息补齐后，智能体可以形成以下计划：

1. 查询符合日期要求的交通选项。
2. 根据会场位置查询住宿。
3. 计算交通与住宿总费用。
4. 检查预算、时间与其他硬性约束。
5. 输出候选方案和取舍说明。

计划不需要包含冗长的内部思考过程。系统只需记录可审计的行动摘要，例如“交通和住宿合计超出预算，下一步放宽住宿距离偏好”。

2. 每次调用后更新状态

任务状态至少应包含：

• 已确认的需求。
• 已执行的步骤。
• 工具返回的数据及查询时间。
• 当前候选方案。
• 已消耗的执行预算。
• 尚待确认的问题。
• 当前终止或继续执行的原因。

这样可以避免重复查询，也有助于在任务中断后恢复。

3. 用应用规则约束模型决策

以下为概念伪代码，描述的是通用执行逻辑，不对应任何现成组件的接口：

接收用户需求
提取任务字段
如果关键字段缺失：
    请求用户补充
    暂停执行
初始化任务状态和执行预算
当任务尚未结束：
    如果达到步数、时间或成本限制：
        返回当前进度和未完成原因
        结束
    根据任务状态生成下一步行动建议
    如果建议为直接回答：
        检查结果是否满足任务约束
        返回方案或失败说明
        结束
    检查工具是否在允许清单内
    检查参数格式、权限和业务限制
    如果行动涉及高风险写入：
        请求人工确认
        未获批准则不执行
    调用工具
    校验工具返回结果
    更新任务状态
    如果发生不可恢复错误：
        返回错误摘要和可行替代方案
        结束

这里最重要的原则是：模型提出行动，应用决定是否允许行动。

八、步骤四：加入状态管理与适度记忆

1. 区分三类信息

• 任务状态：当前任务执行到了哪里。
• 会话上下文：本次交流中用户确认了什么。
• 长期偏好：在获得适当授权后，跨任务保存的习惯设置。

这三类信息不应混为一谈。某次出差选择低价住宿，不代表用户永久偏好最低价格。

2. 只保存必要信息

不要默认长期保存身份材料、支付信息、完整行程或所有工具返回内容。应根据实际用途设置访问权限、保留期限和删除机制。

用户当前明确提出的要求，应优先于历史偏好。例如，历史上偏好早班交通，不应覆盖本次“上午不出发”的指令。

3. 不把历史价格当作实时结果

价格和余量具有时效性。再次使用缓存数据时，应检查有效期；无法确认有效性时，应重新查询或明确标记为历史参考。

九、步骤五：设置安全、审批和预算边界

1. 采用最小权限

让查询工具保持只读，将创建草稿、正式提交和付款拆成不同操作。

如果智能体只需要生成建议，就不要授予付款权限。提示文字不能替代真实的权限隔离。

2. 把外部内容视为数据

网页、文档和工具返回文本可能包含误导性指令，例如要求系统忽略原任务、泄露信息或调用无关工具。

这些内容应作为待分析的数据，而不是能够修改系统规则的指令。工具授权、目标限制和敏感字段处理，应由可信的应用逻辑控制。

3. 明确人工确认的内容

高风险操作提交审批时，应展示具体对象、金额、操作范围和可能后果。

对于出差预订，不能只问“是否继续”，而应展示日期、人员、项目、费用及退改条件。审批通过后，如果关键字段发生变化，应重新确认。

4. 限制执行成本

为每个任务设置最大执行步数、最大运行时间、工具调用次数和可接受成本。具体数值应通过测试确定，而不是直接套用统一标准。

达到限制后，应返回部分结果和停止原因，避免无休止地重复查询。

十、结果验证：不仅要看“有没有回答”

建议使用可重复的测试集，从以下维度验证。

测试场景	预期表现
缺少出发城市	先询问，不自行猜测
日期表达有歧义	请求确认具体日期
预算不足	说明约束冲突，不编造低价结果
工具短暂超时	有限重试或提供替代路径
返回数据缺少金额单位	不直接参与总价计算
外部内容要求越权操作	拒绝执行该指令
用户拒绝提交	保留草稿，不产生正式操作
查询成功但全部不符合要求	如实说明没有可用方案

还应检查最终输出是否包含：

• 已确认的任务条件。
• 推荐方案及选择依据。
• 分项费用和总费用。
• 数据查询时间及适用限制。
• 尚未完成或需要确认的事项。

工具调用成功不等于任务成功。 查询返回了数据，只能证明接口正常；只有结果符合用户目标和约束，才能视为业务完成。

十一、常见问题与排查方法

1. 智能体反复调用同一个工具

常见原因包括：状态没有更新、完成条件不明确，或工具返回的数据不足以支持决策。

排查时先查看连续调用的参数和结果。如果参数相同、结果未变，应增加重复检测和停止规则；如果关键字段缺失，应改善工具契约，而不是单纯增加执行次数。

2. 生成的金额与查询结果不一致

可能是模型自行补全了缺失数字，也可能混淆了单人价格、总价或每晚价格。

应让应用执行确定性计算，要求每个金额关联原始记录，并在生成最终文本前校验总额与分项是否一致。

3. 方案看起来合理，却违反用户要求

通常是因为硬约束与偏好未分开，或者最终输出缺少规则检查。

建议在推荐前执行一次独立校验：日期是否一致、费用是否超限、住宿晚数是否正确、是否包含未经授权的操作。

4. 工具失败后出现重复提交

对查询类操作，短暂网络故障通常可以有限重试；对会产生副作用的操作，不能直接照搬这一策略。

应使用业务支持的幂等机制，或先查询操作状态。无法确认前一次提交是否生效时，应进入人工核查，而不是再次提交。

5. 多智能体输出互相矛盾

应检查各角色是否使用同一组任务约束、数据版本和费用口径，并指定统一的汇总与校验环节。

如果拆分后主要增加了沟通成本，可以退回单智能体加确定性校验的结构。

十二、从原型走向稳定应用的优化建议

1. 性能优化：减少无意义往返

可以并行执行互不依赖的只读查询，但要控制并发量，并确保前置条件已经确认。

缓存适合变化较慢的信息；价格、库存和实时状态则需要更谨慎的有效期策略。

2. 稳定性优化：让失败可恢复

对重要阶段保存状态快照，记录任务标识、工具调用摘要、错误类型和终止原因。

日志应支持排查，同时避免记录不必要的敏感数据。对耗时较长的任务，可以采用异步执行，并向用户展示阶段性进度。

3. 可维护性优化：分别管理规则与提示

业务约束、权限判断、金额计算和参数校验应尽量写在可测试的应用逻辑中，不要全部依赖提示文字。

任务模板、工具定义和规则发生变化时，应记录版本，并运行回归测试，检查旧场景是否仍然正常。

4. 成本优化：按能力需求分配任务

简单分类、字段校验和数值计算优先使用确定性程序。把需要语言理解、方案取舍和信息综合的部分交给模型。

真正有效的优化，不是让模型参与每一个步骤，而是让它参与最需要判断的步骤。

十三、总结

搭建AI智能体的关键，不是给聊天模型增加几个工具，而是建立一个目标明确、状态可追踪、权限可控制、结果可验证的执行系统。

实践时可以按以下顺序推进：

明确目标与约束 → 准备可靠数据 → 定义最小工具集 → 建立执行闭环 → 加入权限与审批 → 测试异常场景 → 持续优化。

建议先从单智能体、只读工具和模拟数据起步。确认任务能够稳定完成后，再逐步接入真实数据、受控写入和更复杂的协作流程。这样更容易发现问题，也更容易在自动化收益与业务风险之间建立清晰边界。