上午九点，培训讲师小林走进会议室，发现投屏设备没有画面。九点半，二十多位新同事就要入场。她打开企业服务台，输入：“A301 会议室投屏没反应，培训马上开始，怎么办？”如果系统只返回一篇长长的设备说明，小林还得自己判断哪一段适用；如果系统直接说“已安排人员处理”，却没有在工单系统留下记录，事情甚至可能没人接手。企业服务台智能体真正有价值的地方，是把一次模糊求助推进成可检查的业务结果：补齐关键信息、找到适用指引、判断能否自助解决；解决不了时，征得同意后创建工单，并把后续进度说清楚。本文以这段虚构但贴近实际工作流程的场景为主线，讨论一个自行编写的 Python Agent 应该承担什么、不该承担什么。文中的会议室、设备记录和工单编号都只是示例；接入真实企业时，必须以已有业务系统、知识版本和处理制度为准。先把需求讲透，后续编写执行循环、工具和知识检索时才知道代码究竟要完成什么。文章目录故事从一句“投屏没反应”开始为什么这件事不只是一个问答机器人把故事写成一张任务卡Agent 在故事中的决策流程图再看一次完整的服务台对话业务系统如何分工，才不会让 Agent 变成万能钥匙如何证明这位“数字服务台同事”真的有用从这个故事走向后续开发总结故事从一句“投屏没反应”开始小林提交的第一句话包含三个信息：地点是 A301，现象是投屏没有画面，时间很紧。它同时缺少决定排查方式的信息：用的是线缆还是无线投屏？设备是否显示错误提示？之前尝试过什么？一个会工作的服务台不会立刻把所有可能方案都倾倒给她，而是先问最能改变下一步判断的问题。下面把这次求助拆成几个业务时刻。时间仅用于说明顺序，不代表系统承诺的处理时长。故事时刻小林看到的交互Agent 背后的判断必须留下的结果提交求助“A301 投屏没反应，培训快开始了。”识别为会议室设备求助，并提取地点与紧急程度建立会话任务，保留原始问题补充信息“现在用的是线缆连接吗？屏幕有什么提示？”当前信息不足，先问能缩小排查范围的问题记录连接方式与具体现象查找指引小林回答“线缆连接，屏幕显示无信号”查房间设备信息及当前有效的投屏指引得到可追溯的资料名称和版本尝试处理按适用指引提示检查输入源与连接状态只给与该
