给业务系统接入智能体的一些取舍

这半年陆陆续续在几个 Java 老系统里塞智能体（Agent）能力——客服问答、工单初分、内部知识检索。踩了不少坑，这里把几个反复纠结的取舍记一下，主要是给以后的自己看。

先问一句：这事真需要智能体吗

最容易犯的错，是把本该写成几行代码的逻辑硬塞给大模型。能用规则、正则、状态机稳定解决的，就别交给模型——它更慢、更贵，还会偶尔“发挥”。我现在的判断标准很糙但够用：

• 输入是结构化的、分支有限 → 老老实实写代码；
• 输入是自然语言、意图模糊、需要“理解”再决定下一步 → 才上智能体；
• 介于两者之间 → 先用模型做意图识别，再把活儿派给确定性的代码执行。

Java 这边怎么接

生态比想象中成熟。我主要在 LangChain4j 和 Spring AI 之间来回选：前者抽象更全、工具调用和记忆都现成；后者和 Spring Boot 那套依赖注入、配置体系贴得更顺，团队上手快。两个都能屏蔽底层模型差异，把模型当成一个可替换的依赖，这点很重要——别让业务代码和某一家模型的 SDK 焊死。

经验：把“调模型”封一层自己的接口，入参出参用自己的领域对象。换模型、加缓存、做降级，都在这一层做掉，上层无感。

工具调用（Function Calling）是关键，也是麻烦

让模型能调用系统里的方法（查订单、改状态、发通知），是从“会聊天”到“能干活”的分水岭。难点不在于让它调，而在于：

• 边界要收死：只暴露只读、幂等、影响面小的工具给模型；写操作一律走人工确认或二次校验，别让它直接 delete。
• 描述比代码重要：工具的名字和参数说明，模型是照着字面意思理解的。一个含糊的描述能让它在错误的时候疯狂调用。
• 失败要能兜住：工具抛异常时，把可读的错误信息回喂给模型让它重试或换路，比直接 500 体验好得多。

知识库检索：别指望模型自己“记得”

业务知识（产品文档、历史工单、内部规范）不能靠模型“背”，得靠检索增强（RAG）。这块我反复调的几个点：

• 切片粒度：切太碎丢上下文，切太大塞不进也召不准。按语义段落切、保留标题层级，比按固定字数切效果好很多。
• 召回不等于答对：向量召回回来的片段还得重排、去重，必要时上一轮关键词检索做兜底，纯向量并不万能。
• 让它“查不到就说不知道”：在提示词里明确约束“仅依据给定资料回答，资料里没有就直说”，能压下大半的一本正经胡说。

幻觉与可控性

给生产系统用，最怕的不是答得不够好，而是答得很笃定但是错的。我的几条土办法：关键结论要求模型给出处（引用检索片段的来源）；高风险动作必须落到“建议 + 人工确认”而不是自动执行；输出尽量约束成结构化 JSON，方便后端校验，而不是一段自由发挥的文字。

成本与延迟

真上量之后，钱和等待时间是绕不开的。几个见效的优化：能缓存的提示词前缀就缓存；简单意图用小模型、复杂推理才上大模型，按需路由；长对话定期做摘要压缩上下文，别把整个历史每次都喂进去。流式输出（SSE）虽然不降总耗时，但首字时间快了，用户感觉完全不一样。

小结

智能体不是银弹，它更像一个“不太稳定但很会变通的新同事”——你得给它划好权限、写清职责、留好兜底，它才能真正帮上忙。对 Java 这种偏稳健的技术栈来说，最舒服的姿势是：让模型负责“理解和决策”，让原有的代码负责“可靠地执行”，两边各干各擅长的事。