第 1.5.1 节：先跑通最小可用 Agent 切片

本节围绕“先跑通最小可用 Agent 切片”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够说清最小可用 Agent 切片的处理顺序、关键检查点和失败处理。

本章要解决什么问题

前几章已经讲了 AI Agent（人工智能体）、模型调用、Token（文本计量单位）、上下文、Prompt（提示词）和结构化输出。本章把这些能力组合成第一个小项目：客服问题分流 Agent。

它是“企业客服知识库与工单 Agent 工作台”的最小切片。这个切片暂时不查询真实订单、不创建真实工单，也不直接执行退款动作。它只负责把用户问题变成稳定的工程结果：

这样做的原因很现实：第一个 Agent 项目如果一上来就接订单系统、退款审批、工单平台和多轮状态，很容易把读者卡死。本章先把骨架做稳，第 1.6 章再把“下一步动作”接到真正的 Tool Calling（工具调用）。

关联作品集项目：智能客服 Agent 工作台。本章使用客服分流口径讲解它的制作方法。

学完本章后，你应该能够：

很多读者听到“第一个 Agent”，会期待一个很完整、很自动化的系统：能查订单、能回答政策、能创建工单、还能处理退款。这个方向听起来完整，但对初学者非常容易失控。

真实工程更稳的做法是先做一个最小切片：让 Agent 把用户问题稳定转成意图、风险、缺失字段、下一步动作和回复草稿。这个切片暂时不真正修改业务系统，但它会决定后续 RAG（检索增强生成）、Tool Calling、工单、转人工和状态管理能不能接住。

这一章的价值是让读者明白：第一个 Agent 不是功能最多的系统，而是第一个可解释、可校验、可兜底的业务闭环。

用户进入客服入口后输入：

我买的设备用了两天就坏了，客服也没人回我，你们到底能不能退款？

第一个 Agent 不应该立刻承诺退款，也不应该假装已经查到订单。它应该做的是：

判断项	结果示例	为什么
意图	退款、售后投诉	用户表达了退款诉求，也表达了对客服的不满。
风险等级	high（高）	涉及投诉和资金结果，不能全自动处理。
缺失信息	订单号、商品名称、联系方式	没有这些信息无法查订单或建工单。
下一步动作	ask_followup（追问信息）或 handoff（转人工）	先收集必要信息，同时准备人工介入。
回复草稿	安抚用户，说明需要订单号，不承诺退款结果	合规且可继续推进。
记录字段	trace_id（追踪编号）、session_id（会话编号）、risk_level（风险等级）	后续能复盘本次处理。

这就是本章要完成的最小闭环：用户输入进入系统，Agent 给出结构化判断，系统根据判断进入下一步。

面试官问“你做过第一个 Agent 项目吗”时，真正想听的是你如何缩小范围、控制风险和证明可用。

真实问法	背后考点	回答方向
你的第一个 Agent 为什么不直接接真实订单系统？	范围控制和风险意识	先验证分流、字段契约、状态日志和兜底；真实工具在第 1.6 章再接。
用户要求退款时，你的 Agent 会怎么做？	高风险边界	不承诺退款，识别风险和缺失信息，要求补充订单信息并准备人工或审批流程。
Mock（模拟）模式和真实模型模式怎么保持一致？	工程契约	两种模式都遵守同一份输入输出字段，不让测试环境和真实环境分裂。
你怎么证明这个 Agent 可验收？	验收样例和日志	用咨询、订单、退款、投诉、缺信息、超范围样例验证，并记录 trace_id（追踪编号）。
如果模型输出无效，你的系统怎么办？	失败兜底	结构化校验失败后重试、降级或转人工，不让无效结果进入工具执行。