按业务要求设计智能体

连接 AI 助手

用智能体开发服务平台（AgentWorks）搭建业务助手，可以从一个实际问题开始：用户想办成什么事，需要哪些资料和工具，做到什么程度才算完成？下面以员工设备服务为例，把这些要求变成能力选择、提示词和测试用例。你可以沿用这套方法，设计自己的客服、采购、报表或运维助手。

明确业务目标与完成标准

假设一名员工问：“我的电脑还没修好，明天要给客户演示，现在该怎么办？”这比“做一个设备助手”更具体，也更容易判断应该给助手哪些能力。

先为这个请求写一份简短的设计说明：

• 要解决的问题：查清维修进度，帮助员工找到临时用机办法。
• 需要确认的事实：电脑是否已经修好；如果可以领取，在哪里、什么时间领取。
• 需要查的资料：备用设备的借用条件、申请方式和联系人。
• 完成标准：说清报修系统查到的事实和制度中的规定，给出有依据的下一步建议。
• 操作范围：第一版只查询和建议，申请和审批在公司的业务系统中完成。

例如，查到借用制度，可以告诉员工怎样申请；如果还要确认有没有空闲设备，就需要再接一个库存查询工具。每增加一项要求，都能据此判断是否要增加资料、工具或处理规则。

判断哪些环节交给智能体

本例需要先查维修状态，再决定是说明领取方式，还是继续查借用制度。智能体的作用是结合用户的问题和刚查到的结果，决定接下来做什么。

• 只是整理现成内容，例如把维修记录写成摘要，可以直接调用模型。
• 每次都必须按固定步骤执行，例如按明确条件审批，适合放在业务代码或工作流中；智能体可以承担其中的理解、说明或总结。
• 需要追问、查询，再根据结果继续处理，可以让智能体组合已配置的能力。本例采用这种方式。

这些方式可以配合使用。例如，智能体收集申请材料，业务系统按固定规则审批。AgentWorks 的运行过程与外部工作流怎样配合，参见区分平台运行循环和外部编排。

按业务需要组合能力

能力不必一次配齐。先看看任务缺什么，再选能补上这一部分的能力。下图是选择范围，不是执行顺序；同一个助手可以同时使用其中几类。

图表预览

资料和记忆提供信息，工具查询或操作系统，提示词和 Skill 说明做事方法，子代理承担专门任务。本例先用知识库、一个报修查询工具和提示词，就能完成“查进度、给建议”；其他能力可以等业务需要时再加入。

选对资料来源

同样是“查信息”，不同内容适合放在不同地方：

• 查公司的制度和手册：使用知识库组。例如检索备用设备借用制度，并在回答中说明依据。
• 查外部的公开新资料：使用联网搜索。例如采购助手查厂商最新产品资料，再与内部采购规定对照。需要准备 Tavily 凭证，搜索词中应避免包含内部敏感信息。
• 查业务系统此刻的状态：使用查询工具。例如报修进度、库存和订单状态，都以本次查询结果为准，对话历史不能代替实时查询。
• 下次交流还要记住信息：使用记忆库。例如保存员工确认过的设备偏好；保存个人信息前，先明确谁能读取、修改和删除，不能把个人资料直接放进其他员工也能访问的共享记忆库。

把资料名称和用途写具体，也有助于智能体选对来源。“备用设备借用制度：借用条件、申请流程和联系人”就比“员工资料”更容易区分。

选择工具在哪里执行

智能体决定何时请求工具，真正的操作在对应环境中执行。可以根据已有系统和任务需要选择接法，不必为同一项查询同时接入多种方式。

你的情况	选择的能力	操作在哪里完成
已有远程 MCP 服务提供所需工具	MCP	远程 MCP 服务
自己的应用能访问业务系统，并掌握登录用户的身份	用户工具包	调用智能体的业务应用
需要渠道媒体发送、定时任务等平台现成能力	平台工具包	AgentWorks 平台
需要运行命令、执行脚本或处理数据文件	沙箱	配置的沙箱环境

需要让智能体读写文件时，还可以选择文件系统工具及其读写范围。例如做月度维修报表，可以在沙箱中挂载存放报表的对象存储目录，准备分析脚本所需的依赖，再约定输出位置。本例只查制度和报修状态，不处理文件，应关闭文件系统。

如果想让助手每天汇总未完成的报修单，需要提供能列出授权范围内未完成工单的查询工具，例如平台可直接调用的远程 MCP 工具，再增加平台定时任务工具包。这样，平台可以按时把汇总请求交给智能体。先确认租户中有该工具包，并通过绑定渠道验证触发时间和回复；设置方法见验证定时任务。

复用团队方法，或请专业助手协作

几条简单判断可以直接写进提示词。需要反复使用一套方法时，可以整理成 Skill；需要不同专业分工时，再考虑子代理。

• 一套方法要给多个助手复用：例如月度报表的统计口径、异常判断和报告格式，可以整理为 Skill，通过技能组提供给助手。Skill 中可以附带脚本和参考资料；脚本需要的运行环境与依赖要在沙箱中准备，添加 Skill 不会自动执行脚本。
• 任务需要不同专业分别处理：例如设备故障排查和采购方案评估，可以由主智能体按需委托给两个子代理。为每个子代理写清适合的任务、所需输入和返回内容，并先单独验证它能完成工作。

Skill 解决“按什么方法做”，子代理解决“交给哪个专业助手做”。主智能体可以选择一个或多个子代理，也可以自己处理简单问题；拆分后，每个助手的工具和数据权限仍需要分别配置。

用一个请求串起判断与行动

回到员工设备助手。假设公司已有员工服务应用、报修系统和借用制度：应用通过 API 调用智能体，用用户工具包执行只读报修查询，知识库提供制度。下面的工具名是设计示例，实际搭建时需要接上自己的业务系统。

图表预览

员工没有提供单号时，助手先追问。查到“已可领取”，就说明领取方式；查到“仍在维修”，再查备用设备借用制度。查询失败或无权访问时，说明无法确认进度，不把失败当作“还没修好”。制度中没有答案时，也应说明缺少什么信息，并提供资料中已有的联系途径。

同一句问题会因为查询结果不同而得到不同处理。这张图帮助你写提示词和设计测试，并不会自动变成平台中的固定工作流。

让查询工具返回足够的信息

本例的工具叫 get_repair_status。工具描述应说清“按报修单号查询当前维修状态和领取信息”，并约定：

• 输入：报修单号。
• 成功返回：当前状态、最近更新时间；已可领取时，附上领取地点和时间。
• 失败返回：查询失败、单号不存在或无权访问。
• 允许的操作：只读查询，不修改工单、不批准申请。

员工服务应用从登录信息中确认员工身份，检查他是否有权查看这张单，再执行查询并把结果交回智能体。员工身份和权限不能让模型猜测。具体接法见用户工具包的运行过程；如果已经有远程 MCP 服务提供报修查询，可以改用 MCP。

把判断规则写进提示词

提示词主要说明职责、判断和回答要求。实际工单数据通过工具取得，具体制度从知识库查，不必都抄进提示词。

你是员工设备助手，帮助员工确认维修进度并找到临时用机办法。

用户询问报修进度及后续安排时，先确认报修单号，缺少单号就追问。
使用 get_repair_status 查询，只依据本次返回说明维修状态。
已可领取时，说明返回的领取信息；信息不全时，请员工联系服务台确认。
仍在维修且需要临时用机时，查借用制度，说明条件和申请方式。
用户只问借用制度时，直接检索制度，不要求提供报修单号。

查询失败或无权访问时，说明无法确认进度，不要按“仍在维修”继续判断。
制度没有答案或缺少必要条件时，说明缺少什么信息，再追问或提供联系途径。
联系人只使用资料或工具提供的信息，不编造维修期限、库存或借用条件。

回答区分报修系统的事实和制度中的规定，不承诺申请一定获批。
不批准申请、不修改工单；这些请求按制度中的申请途径办理。

制度变了，更新知识资料；工具返回内容变了，调整工具定义和处理程序；助手的职责或判断规则变了，再修改对应提示词。配置方法见编写可验证的系统提示词。

设计追问、审批与失败处理

一个好用的助手，既要在信息齐全时办事，也要在缺信息、遇到重要操作或查询失败时，知道怎样继续。可以从员工最常遇到的几种情况来选配置。

缺信息时追问，重要操作前确认

需要员工选择设备类型、补充使用时间时，可以启用用户提问，用文本、单选或多选收集信息。把“缺哪一项就先问，不猜着填”写进提示词，能让下一步操作有明确依据。

如果第二版要从“告诉员工怎样申请”升级为“帮员工提交申请”，就需要接入真正的申请工具。为查询、提交和删除等业务工具操作分别设置工具权限与审批，并确认目标渠道能完成审批。申请提交后，以业务系统返回的申请单号和状态说明结果；批准一次工具调用，不等于公司的业务审批已经通过。

查询失败时，工具处理程序返回明确的错误，助手说明哪些信息已确认、哪些还查不到，并给出人工处理途径。超时和重试在工具程序中安排，业务系统继续按真实身份校验权限，不能只靠提示词中的限制。

为多步任务和长对话选择辅助功能

这些设置解决的是不同问题，可以按需要搭配：

• 一次任务有好几个环节：使用待办列表（Todo）列出并更新当前任务的步骤。需要跨会话保留进度、自动继续后续步骤时，使用工单或工作流系统。
• 一次对话聊得很长：启用上下文压缩，把较早的内容整理成摘要，让后续处理能继续。测试时检查重要事实是否保留；压缩不等于把信息存入记忆库。
• 需要判断今天、明天或截止日期：检查是否注入当前时间，同时明确业务时区。定时发起任务使用前面的平台定时任务工具，不能只靠时间信息触发。

具体开关和字段见智能体模板配置。不用的能力可以保持关闭；例如本例不读写文件，应关闭默认开启的文件系统，而不是只清空工具选择。

复用设计，区分用户和部门配置

第一版验证通过后，如果要让多个部门使用同一套助手，可以用同一份智能体模板创建多个实例。职责和方法在模板中统一配置；创建实例时，再填写模板开放的参数，例如各部门自己的 MCP 服务凭证。

假设研发部和销售部都采用同一套设备服务规则，报修查询改由远程 MCP 服务提供，但两个部门使用不同账号。可以共用制度知识库组实例，并关联一个将凭证设为可配置的 MCP 模板：

图表预览

图中两个智能体实例来自同一份模板，共用同一个制度知识库组实例；平台在创建各智能体实例时，按关联的 MCP 模板和各自填写的凭证创建 MCP 实例。因此，工作方法可以相同，访问业务系统所用的账号可以不同。

创建实例前，需要在 MCP 模板中开放对应字段，并在智能体模板中给参数设置容易理解的名称。实例中只能填写模板开放的参数。具体做法见使用 MCP 模板生成独立连接。其他能力的模板和实例各有差异，不能都套用 MCP 的传参方式，参见能力模板与实例的选择、关联与复用。

共用资源适合大家本来就能访问的资料；个人记忆、私有文件和业务凭证则要明确各自的访问范围。单独创建智能体实例并不会自动隔离它所连接的共享资源，业务服务也要按凭证校验权限。

选择员工的使用入口

设计助手时，也要确定员工从哪里使用它，因为入口会影响工具的接入方式。网页版对话适合初步试用；飞书、QQ 适合已有聊天习惯的团队；自己的员工服务应用可以通过 HTTP 与 WebSocket API 调用智能体，接入登录身份和应用内操作。

渠道也会影响实例的使用方式：

• 大家使用一个已经配好的助手：渠道绑定已有智能体实例。共享实例不等于所有人共用同一段单聊历史，也不等于数据资源自动按用户隔离。
• 为每位渠道用户开通自己的助手：渠道绑定智能体模板，用户通过 /init 创建专属实例，并按模板要求提供参数。

选择时一起确认谁能发消息、谁能批准工具调用，以及消息会送到哪个实例。配置方法见选择智能体的使用方式。

如果保留本例的用户工具包方案，报修查询需要通过实现了工具处理程序的员工服务应用完成。仅把入口改为飞书或 QQ，不会替应用执行查询代码；要直接在这些渠道使用，应改用平台能调用的远程工具方案。

创建测试实例，验证业务结果

设计完成后，可以按下面的顺序搭建本例的第一版。先验证“查进度、给建议”，再为新增能力补测试，不必一次接齐所有系统。

1. 准备现行借用制度，创建并验证知识库组，确认能查到借用条件、申请方式和联系人。

2. 实现只读报修查询，处理员工身份、工单权限和错误返回；按同一约定准备用户工具包定义。

3. 创建智能体模板，选择模型，填写提示词，关联知识库组和用户工具包，关闭本例不需要的文件系统。

   模型和思考设置会影响回答质量与响应速度。可以用下面同一组测试题比较候选模型，选出能正确使用工具、遵守规则且响应表现合适的配置，再按需要调整模型参数。

4. 从模板创建测试实例，让员工服务应用调用它，接收工具请求、执行查询并回传结果。

   注意

   用实际入口验证工具

   知识检索可以先在网页版对话中检查；完整的报修查询要通过已实现工具处理程序的员工服务应用测试。

5. 准备不同的查询结果，在独立测试会话中检查助手的选择和回答。

用不同结果检查同一个请求

例如发送“报修单 A-1042 的电脑明天演示要用，现在怎么办？”，分别让测试工具返回“已可领取”和“仍在维修”，检查助手是否改变后续处理。下面的状态都是测试条件，不是真实工单数据。

测试条件	应怎样处理	回答中要检查什么
已可领取，并返回领取信息	查报修状态，不额外查借用制度	领取地点和时间与工具结果一致
仍在维修	查报修状态，再查借用制度	区分维修事实和制度规定，说明申请方式
员工没给报修单号	追问单号后再查	不猜测单号
员工只问“备用电脑怎么借”	直接查借用制度	不要求提供报修单号
查询超时或被拒绝	说明无法确认进度	不按“仍在维修”继续处理
仍在维修，但查不到借用制度	说明已知状态和缺少的资料	不编造借用条件和联系人
员工要求批准借用或关闭工单	不执行超出范围的操作	说明已有的申请途径

在 Trace 中核对调用了哪些工具、检索了哪些资料，在应用日志中核对权限检查和查询结果，再看回答是否忠实使用了这些信息。这样能区分“回答听起来合理”和“确实按设计完成了任务”。

如果不同维修状态总是触发同一套查询，检查提示词和工具描述是否说清判断条件，工具返回是否足以区分状态。测试通过后，再加入员工常用的说法、连续追问和真实异常；增加记忆、写入工具、定时任务或子代理时，也补上对应测试。

需要跟着完整实战练习知识与业务查询的组合，可以继续阅读构建知识与工单协同的服务台助手。该实战有自己的样例资料和工具，你可以借鉴它的搭建方法接入公司的报修系统。