199、Agent进阶项目实战：构建通用助手

199、Agent进阶项目实战：构建通用助手

那段时间我差点被一个“万能”的助手搞到自闭。场景是这样的：我在做一个内部用的通用助手，想让它既能查数据库、能调内部API、能读写本地文件，还能在用户问“今天天气怎么样”的时候，自动去请求天气服务。听起来挺美好对吧？结果第一个版本跑起来之后，用户说“帮我查一下昨天订单” —— 它愣是去调了天气API。更离谱的是，当它发现天气API返回失败，竟然尝试“修正”我的数据库连接字符串。

我盯着日志看了半天，脑子里只有一个念头：这玩意儿不是通用，是“失控”。

后来我逐步拆解，才意识到通用助手的核心根本不是“能接多少工具”，而是“怎么决定用哪个工具”——也就是agent的决策链路。今天这篇笔记，就是把这个坑填平的过程，顺便聊聊我在实战里趟出来的几个关键点。

先说说那个触发我重写的bug。日志显示，agent收到“查订单”请求后，它的推理链路里出现了这么一段：user wants info about order, maybe weather affects logistics? Let me check weather first。看到没？它在自作聪明地建立因果。这暴露了一个深层问题：我在设计prompt时给了它太多“自主性”，却没有给它“决策边界”。你让一个语言模型自由联想，它真的会给你自由到珠穆朗玛峰。

第一个教训：通用助手的工具选择策略，不能靠模型“灵光一现”。必须给工具加上显式的“适用范围”和“否定条件”。我当时把工具的description写成“查询订单信息”，太模糊了。后来改成“仅当用户明确提到‘订单’、‘发货’、‘物流’等关键词时使用；如果用户询问天气、日期、新闻，不要