跳到主要内容

第 1.1.3 节：把目标、上下文、工具和边界画成 Agent 架构

进入实现之前，先围绕“把目标、上下文、工具和边界画成 Agent 架构”划清适用场景、不做范围和判断条件。完成本节后，你应该能够画出目标、上下文、工具和边界的组成模块、数据/状态流、责任边界和上下游依赖。

实现步骤或决策流程​

读图重点：模型只负责提出下一步，应用层负责资料范围、权限、执行和审计。

客服工作台落地顺序​

把“企业客服知识库与工单 Agent（智能体）工作台”落地时，不要从“我要做一个全自动 Agent”开始，而要按风险逐步收口。

顺序落地内容为什么这样做
1明确问题类型：咨询、查订单、退款、投诉、超范围先知道系统要处理什么，才能判断是否需要 Agent。
2先做知识问答边界低风险问题可以先通过 RAG（检索增强生成）和引用回答解决。
3再列工具动作查订单、查物流、创建工单都需要受控工具，不是模型自由回答。
4标记高风险动作退款、补偿、投诉升级必须有人工确认或审批。
5设计 Agent 决策层只有当系统需要动态选择“回答、查资料、调工具、转人工”时，才引入 Agent 编排。
6加状态、日志和验收样例让每一次处理都能复盘，避免只在演示里看起来能用。

推荐技术流：先判型，再设计​

面对“做一个 AI（人工智能）客服”的需求，不要直接选框架。先按下面流程判型。

步骤要问的问题推荐结果
1用户只是想要一个自然语言入口吗？可以先做 Chatbot（聊天机器人）。
2回答是否必须来自企业资料？加 RAG 和引用来源。
3是否要查询订单、物流、余额、工单？引入 Tool Calling（工具调用），并做权限校验。
4是否要多轮收集信息、判断下一步、处理失败？设计 Agent 状态和停止条件。
5是否涉及退款、投诉、隐私或合规？加人工审批、转人工和审计日志。
6是否可以用固定流程稳定解决？优先用 Workflow（工作流），不要为了追新词过度 Agent 化。

实现步骤：从需求判断到 Agent（智能体）设计​

第 1 步：明确目标​

不要写“做一个万能 AI 客服”。应该写成：

用户输入售前或售后问题后，系统先从知识库回答；如果涉及订单、退款、投诉或账号问题，调用对应工具或转人工，并记录处理过程。

第 2 步：划定边界​

需要回答：

  • 它能访问哪些资料？
  • 它能调用哪些工具？
  • 哪些操作需要人工确认？
  • 哪些问题必须拒答？
  • 什么时候停止？

第 3 步：设计工具​

例如客服 Agent 可以有：

工具能力作用关键边界
搜索知识库从企业资料中找到可引用依据不能把无来源内容当成企业政策。
查询订单状态读取当前用户订单、物流或售后状态必须校验用户身份和订单归属。
创建客服工单把用户诉求交给客服系统处理写入前需要用户确认摘要。
转人工把高风险或无法判断的问题交给人工要记录转人工原因和会话摘要。

第 4 步：设计状态​

状态包括：

  • 当前用户身份。
  • 当前问题分类。
  • 已调用工具。
  • 工具返回结果。
  • 是否需要人工审批。
  • 最终处理结论。

第 5 步：设计失败处理​

常见失败包括：

  • 知识库没有答案。
  • 工具调用失败。
  • 用户信息不完整。
  • 模型输出不符合格式。
  • 任务超出权限。

Agent 项目的质量，往往取决于失败处理，而不是成功路径。

字段契约与配置说明​

下面是一个简化的契约示意。它不展开代码实现，只用于说明 Agent 如何通过工具连接业务系统。

客服工作台最小契约说明​

本节只说明制作方法，不展开代码语法。进入真实项目开发时，要把本节的输入、输出、工具、日志和验收规则落实到系统结构中。

环节需要明确的内容验收方式
请求进入用户问题、身份、业务对象和会话编号能复现同一次请求
智能体处理角色、提示词、工具、资料范围和停止条件典型任务能稳定走完
工具调用工具名称、权限、输入字段和失败处理高风险工具需人工确认
结果返回答案、依据、风险、下一步动作和拒答原因前端和业务人员能理解
运行记录追踪编号、耗时、模型调用、工具结果和人工确认问题能追溯和复盘

这个例子强调两点：

  1. 工具接口要有清晰的数据契约。
  2. 工具函数背后可以接真实业务系统，也可以先接 Mock（模拟）服务。

版本与资料来源​

本章为概念章。

主要资料入口：

过时风险：Agent 相关 API 和 SDK（软件开发工具包）变化较快。涉及具体代码时，优先查看官方文档和版本说明。

继续学习​