你好，我是 kaii

任何 Agent 应用的起点都是把一次对话做稳：流式输出让用户不用干等，多轮上下文让对话能接住，历史按 token 预算裁剪避免越聊越贵。这一步不涉及智能，但没有它后面都无从谈起。

光会说不够，Agent 得能查数据。把业务接口包装成带描述和参数 Schema 的工具，让模型根据问题自己决定调哪个。执行结果回灌模型，再组织成自然语言。

关键词匹配的死穴是同义表达 —— 问「邮费」查不到「运费怎么算」那条。把文档切块、嵌入成向量、存进向量库，检索就按语义而不是字面。

纯向量对精确型号不敏感，纯关键词对同义说法无能为力。两路同时召回再融合，然后交给重排模型精筛 —— 粗排要宽，精排要准，这是两条不同的活。

单轮 tool-calling 接不住「先查订单拿单号、再查物流」这类多步业务。「知识类必先检索」「投诉不进 Agent」这些约束如果只写在提示词里，模型随时可以不听。改成用图编排把确定性路径焊死，中间放一个 Agent 节点处理灵活部分。

用户说「它能退吗」，这句话脱离上下文毫无意义。指代消解负责补全，意图识别负责分流，缺订单号时弹选择器让人点，而不是让模型猜。

把全量历史递给模型，轮数一多 token 必爆、成本飞涨。双层结构解决这件事：最近几轮留原文保真，更早的压成摘要，滑窗按 token 上限兜底。

几个写死的工具撑不起真实业务。统一注册、校验、鉴权、执行、审计之后，工具才能真正扩张 —— 包括接入外部工具生态。

线上不能是个黑盒 —— 每一步想了啥、调了什么工具、花了多少 token，都该能查。答不上来的问题也不该丢掉，它们是最好的补库素材。

不是所有任务都该交给大模型。说法无穷、类目固定、要快要便宜 —— 这种场景微调一个小分类器，比让大模型逐条判断划算得多。