深夜低代码笔记

说实话我最近也踩过类似的坑，一开始图省事用单Agent，结果HR文档的语义检索老是把技术文档的术语扯进来，准确率掉得厉害。后来拆成三个领域Agent，每个带独立的embedding和提示词，效果立竿见影，路由那层其实用一个轻量分类模型就够了，成本没想象中高。我的经验是宁可让每个Agent小到专注，也别让它大到什么都懂，尤其是在企业内部文档语义差异大的场景下。你可以先按文档类型粗粒度拆，跑一轮bad

说实话我觉得你这问题可能不在chunk上，bge-m3对长文本的语义捕捉其实还行，512的窗口加50的overlap对大多数段落来说不算太碎。我怀疑是检索本身的问题，余弦相似度在faiss里跟内积混用容易出偏差，你试试换成内积或者调下index的参数？另外query理解那步确实值得加，直接拿“报销流程多久到账”这种口语化问句去匹配正式文档，词面差距太大了，先用LLM提取下关键实体和意图再检索，效果

我们这边也测了，响应慢是真痛点，超时参数不调直接崩，其他倒还好。

8G显存跑7B其实没那么玄乎，我拿3070试过Qwen2.5-7B的int4量化版，llama.cpp加载之后大概占6.5G左右，能跑起来，但上下文长度得控制住，超过2K就开始明显变慢。你如果只是做内部知识库问答，建议直接上AWQ或GPTQ量化，配合vLLM或Ollama，吞吐会舒服很多。不过要注意3070的显存带宽只有448GB/s，跑生成任务时token速度大概就20-30/s，多人并发基本别

vLLM对显存的管理比TGI更省，量化的话先试AWQ，4bit在客服场景掉点不大，但一定要在真实对话样本上做对比测试。另外你提到的外部API调用，强烈建议用tenacity库做重试，配合超时和熔断，别让上游故障拖垮整个Agent。预算有限就别上K8s，直接docker-compose部署，配个简单的watchdog脚本就够了。生产链路里最容易被忽略的是日志追踪，建议用LangSmith或者自建一个

8G跑7B确实紧巴，量化后速度和质量都崩很正常，想兼顾就试试3B或4B的模型吧。

StaffDeck这个思路确实切中了多Agent协作里状态管理和角色边界模糊的痛点，但我比较担心“绩效”这种抽象概念的落地方式——在实际工程里，Agent的行为评估往往依赖具  体业务指标，如果平台层强制引入一套通用绩效框架，反而可能把简单的角色编排复杂化。另外，岗位定义自动生成行为约束这块，如果

同问！最近也在思考这个问题，有没有大佬来分享下经验？