美团员工：羡慕隔壁 LongCat 团队的兄弟，作为公司 AI 战略的王牌，已经成为 C 端小团、B 端 NoCode 等产品基座。这种资源一路绿灯的团队，年终奖和晋升肯定不会少（附 Agent 面试题）

周末和一位团子的朋友交流，他说内部对 LongCat（龙猫）非常重视。

我只能说此言不虚。😄

看了一下团子第二季度的财报，研发投入 77 亿元，其中大部分砸向了自研的大模型 LongCat 和其他 AI 场景的落地。

其中 LongCat-2.0 有 1.6 万亿参数，和混元Hy4 preview、GLM-5.3、DeepSeek V4 一样，都是 MoE（混合专家）架构，每次推理只激活 480 亿参数，完全用国产芯片（华为昇腾、摩尔线程、沐曦）训练。

不过，美团 CEO 王兴在财报会上明确表态，“美团不会成为 Token 工厂”。这意味着美团并不打算去卷通用的大模型，而是把 AI 严格限定为效率工具和业务基础设施。

它的核心逻辑是，用 LongCat 做底座，用小团和小美做 C 端入口，用袋鼠参谋等做 B 端提效，最后用无人机和机器人把 AI 的能力延伸到物理世界的配送中。

不过，我个人觉得，Token 工厂蛮赚钱的，毕竟往后去，Token 少不了啊。谁的钱都可以钱，唯独 Token 的费用不能欠。

就像电费、水费、燃气费一样，一旦成为像水电燃气一样的日用必需品，不做 Token 工厂真的蛮可惜。

当然了，做 Token 工厂，也要投入巨大的算力，前期成本也很高，随着时间的推移，我觉得如果团子能再稳定发展两三个季度，就会重新站起来。

因为本质上，美团的护城河并没有变：高频本地需求 × 城市商家供给 × 即时履约网络。

如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人，那接下来的硬核内容，希望你能认真读一读。

（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗发～）

content

01、你当时为什么会想到做这个智能运维 Agent 项目？

“运维场景的痛点太明显了。一个线上告警进来，工程师要登录好几个系统，先看监控面板，再翻日志，再查配置变更记录，再对照运维文档。大部分时间花在信息收集上，真正做判断的时间反而很短。”

“Agent 能把信息收集这个环节自动化。接到告警后自动检索相关的运维文档和历史 case，调用工具查日志、拉指标，把相关信息汇总好，给出初步判断。运维只需要确认和执行就好了。”

底层参考的RAG项目派聪明已经部署上线，大家可以免费体验：https://smart.paicoding.com/

02、系统运转流程是怎样构思的，技术选型的依据是什么？

“用户输入告警描述或运维问题，Agent 先做意图理解，判断是要查文档还是要执行操作。然后调 RAG 检索相关的运维文档，把检索结果注入上下文。Agent 结合检索结果做推理分析，需要更多信息就继续调工具查日志、拉监控指标，最终输出排查建议或直接执行操作。”

“选型有几点考虑。选 Spring AI 是因为公司后端技术栈是 Java，团队熟悉。ES 是因为它同时支持向量检索和全文检索，一个组件搞定混合检索，不需要再引入专门的向量数据库。Embedding 用的是阿里的 text-embedding-v4，2048 维，中文效果不错。推理模型用 DeepSeek 和 Qwen，性价比高。”

03、为什么使用 RAG？模型上下文窗口已经很大了，为什么不直接把文档都交给 Agent？

“上下文窗口大不意味着应该把所有文档都塞进去，有三个关键原因。”

“第一个是成本。运维知识库可能有几百篇文档，每次请求全量送进去，token 消耗太大了。RAG 按需检索，每次只取最相关的几个片段，成本可控。”

“第二个是准确率。研究表明模型处理长上下文时，会遗漏中间部分的信息——所谓的「Lost in the Middle」。文档越多，相关信息被淹没在无关内容里的概率越大。”

“第三个是实时性。文档更新之后，RAG 只需要更新索引，不需要每次都重新组装输入。全量塞入的方式，文档一变就得改输入流程。”

“RAG 还有一个好处是可溯源，每条检索结果带着文件名、页码、匹配分数，回答里的每个论点都能追溯到原始文档。”

04、RAG 和让 Agent 通过 grep 自行检索，不考虑 token 时各有什么优劣？

“RAG 的优势是语义理解。用户搜「内存不够了」，RAG 能召回「OOM 问题排查指南」「Java 堆空间溢出处理」这些文档，因为向量嵌入捕捉了语义上的相关性。但 RAG 需要一套预处理——切块、嵌入、索引，文档格式变了或者嵌入模型换了，整套流程都得重新跑。”

“Agent grep 的优势是精确匹配和零预处理。搜一个错误码、一个配置项、一个函数名，grep 直接精确命中，不需要提前做索引。而且文件改了，grep 搜的就是最新内容，没有索引更新的延迟。但 grep 没有语义理解能力——搜「内存不够了」找不到「OOM」，因为字面上没有交集。”

“Claude Code 就是用 ripgrep 做代码搜索的，不用 RAG。因为代码是精确的，函数名就是函数名，grep 加正则表达式就够了。Agent 可以根据第一轮搜索结果调整关键词，迭代几轮就能找到目标。”

“但运维文档是自然语言描述的，同一件事有很多种说法。这种场景下 RAG 的语义匹配明显占优。我的做法是知识库用 RAG，代码仓库用 grep，按内容类型选方案。”

05、RAG 中间哪些步骤对你构成了挑战，并会影响最终效果？

“挑战最大的是切块和检索排序。”

“切块的难度在于粒度。块太大，一个 chunk（切出来的文本块）里混着多个主题，虽然检索到了，但噪音多，模型生成的回答容易跑偏。块太小，上下文被切断了，模型看到一段话不知道在说什么。”

“我们最终用的是 512 字符一个块、100 字符重叠。512 在运维文档里差不多是两三个自然段，刚好能覆盖一个完整的操作步骤或故障描述。”

“检索排序的难度在于权重配比。BM25 和向量得分的打分范围不一样，直接加权没有意义，得归一化之后再配比。我们目前 KNN（最近邻）权重 0.2、BM25 权重 1.0，关键词匹配的权重更高——因为运维文档里有大量专有名词和错误码，精确匹配比语义匹配更重要。”

06、如果你的 Markdown 文件没有标题，要怎么切分？

“先按双换行切段落，一个段落就是一个候选块。段落太长了，再按句号、问号、感叹号这些句子边界切分。切完之后检查短块，比如说两个相邻的短块加起来没超过上限，就合到一起，避免产生太碎的片段。”

“还有一个做法是父子文档。父 chunk 用大窗口，差不多一整个章节的大小。子 chunk 做细粒度切分。检索的时候用子 chunk 做匹配，命中之后把对应的父 chunk 送给模型，保证上下文完整。两层都存在 ES 里，通过 chunk ID 关联。”

07、混合检索中，关键词检索和向量检索各有什么缺点？

“关键词检索（BM25）的缺点是没有语义理解。它只做词频统计和精确匹配。搜「内存不够了」，包含「OOM」「OutOfMemoryError」的文档一条都召不回来，因为字面上没有交集。同义词、缩写、中英文混用，BM25 全都处理不了。”

“向量检索的缺点是对精确关键词不敏感。用户搜一个错误码「ERR_10042」，向量检索有时候会把一篇泛泛而谈的、错误处理的文档排在前面，因为在向量空间里这两个内容的距离差不多。运维场景下这个问题尤其严重——错误码、配置项、IP 地址这些精确信息，向量检索经常搞混。”

“混合检索就是让两者互补。我们的做法是先用向量 KNN 召回一个大候选集，再在候选集上跑 BM25 重排序，让精确匹配好的结果排到前面。”

08、短 query 与长 chunk 向量化后怎么比较？

“chunk 可能有一两百个字，嵌入之后向量的信息密度高、语义方向明确。query 只有三五个字，嵌入之后向量信息密度低、方向模糊。两个向量做相似度计算，短的一方天然吃亏——它的方向不够「具体」，和很多 chunk 的相似度都差不多，区分度不高。”

“解决方案有两个方向。一是查询扩展，把短 query 补充成更完整的表述。比如用户输入「OOM」，扩展成「Java 应用 OutOfMemoryError 内存溢出排查方法」，补齐语义上下文。”

“二是 HyDE（Hypothetical Document Embeddings，假设性文档嵌入）。先让 LLM 根据 query 生成一段假设性的回答文本，用这段文本的向量去检索。假设性文本的长度和知识库里的 chunk 接近，信息密度对齐了，检索效果比直接用短 query 好不少。”

你有没有对比过长 query 和短 query 在向量召回上的差异？

“对比过。三五个字的 query 召回精度确实差不少。只有一个关键词的时候，向量方向太泛，召回的前 5 条里可能只有 1 条是真正相关的。换成一句完整的话，相关的能到 3 到 4 条。”

“这也是我们把 BM25 权重设得比向量高的原因之一。运维场景下用户经常就丢一个错误码过来，三五个字，BM25 反而比向量检索靠谱。”

09、除了压缩以外，对长 query 还会做什么处理？

“第一个处理是意图分解。用户写了一大段，里面可能混着两三个问题。拆成多个子查询分别检索，每条 query 只对应一个意图，召回精度比一条混合 query 高得多。”

“第二个是关键词提取。从长文本中提取核心实体和术语，用这些关键词做精确匹配补充语义检索。”

“第三个是去噪。用户输入里经常有礼貌用语、重复表达、无关的背景描述。这些在检索前要去掉，否则会冲淡 query 向量的语义信息，让方向变模糊。”

10、剩余 1% 到 2% 的错误怎样识别？

“第一道防线是 LLM-as-Judge（模型裁判）。定义一组评分标准，回答和引用内容是否一致、有没有幻觉、有没有遗漏关键信息——让模型自己打分。好处是成本低、速度快，能覆盖大批量样本。”

“第二道是人工校准。定期随机抽一批模型评过分的样本，人工复审，算一致率。一致率低了说明评分标准漂移了，要调整。两道缺一不可——只用模型裁判，评测体系自己漂移了都不知道。”

“第三道是置信度阈值兜底。模型输出时能拿到 token 级别的概率分布，整体置信度低于阈值的回答标记为「不确定」，提示用户人工确认。”

有没有考虑给产出增加检测机制？

“考虑过引用核验。让模型输出的时候标注引用来源，然后用另一个 LLM 检查引用的原文是否真的支持这个结论。”

“原理类似 NLI（Natural Language Inference，自然语言推断）。把模型的结论和引用原文做蕴含关系判断：支持、矛盾、无关。矛盾或无关的就是幻觉，直接标出来。”

11、Agent 和 Harness 分别是什么？有什么区别？

“Agent = Model + Harness。Model 就是 LLM，负责理解问题、制定计划、做判断；Harness 负责把想法落地，调用工具执行具体操作，查数据库、调 API、读文件等等。想的是 Model，做的是 Harness，两者组合起来不断 ReAct，就是一个好 Agent 了。”

“Harness 是包在 Model 外面的一层工程设施。Model 负责要做什么，Harness 负责这些事在什么约束下、怎么安全地落地。Prompt 怎么组装、上下文怎么管理、工具怎么注册、权限怎么控制、日志怎么记录——这些都是 Harness 的职责。”

Harness 做了哪些事情，能让 Agent 更好地执行任务？

“具体来说有这么几件事。”

“Prompt 组装——把系统指令、用户输入、工具结果、对话历史按层级拼接，决定模型每一轮能看到什么信息。这个顺序和内容直接影响模型的行为。”

“上下文管理——窗口快满了的时候，决定压缩什么、保留什么、裁剪什么。”

“工具注册与调度——管理所有工具的 Schema（参数说明），执行工具调用，处理并发。多个工具没有依赖关系的时候可以并行跑，我们的 PaiCLI 上限是 4 个。”

“权限控制——哪些工具可以自动执行（读文件），哪些需要用户确认（写文件、执行命令）。这是 Agent 落地到生产环境必须有的安全边界。”

“日志审计——每一步的输入输出都有记录，出了问题能回溯。”

“之前看到一个说法我觉得总结得挺到位的——Weak loop Strong tool（弱循环、强工具）。循环这部分各家做法都差不多，无非是上下文拼接和格式处理。能拉开差距的是工具能力和定制化的程度。”

12、上下文过长时，哪些该送、哪些该裁剪？System Prompt 怎么写？

“我们做了两层压缩。”

“第一层压缩的是短期记忆。记忆条目超过 token 预算时，用 LLM 做摘要压缩，保留关键信息，最近几轮的记忆不压缩。”

“第二层压缩的是对话历史。每轮 LLM 调用前检查总 token 数，超过阈值就压缩。压缩的时候保留最近 3 轮完整交互——包括工具调用和工具返回结果，因为切断 tool_call 和 tool_result 的配对会导致模型理解出错。历史部分用 LLM 摘要替换，摘要保留：关键诉求、已完成操作、达成共识、待办事项。”

“该送给 LLM 的，包括系统指令、当前任务描述、最近几轮的工具调用和结果、用户最新输入。不该送的，包括已经完成的任务细节——摘要就够了；重复出现的工具调用结果；过长的工具输出——截断到关键部分就行。”

“System Prompt 用来定义角色、行为边界、工具使用策略、安全规则。这些在整个会话期间基本不变，放在最前面。因为 Prompt Cache 是按最长公共前缀命中，静态内容越靠前、越稳定，缓存命中率越高。”

13、你了解 Prompt Cache 吗？

“Prompt Cache 的原理是按最长公共前缀缓存。”

“LLM API 收到请求后，检查当前请求的 Prompt 和最近请求的 Prompt 有多少前缀是完全相同的。相同的部分直接复用之前的计算结果，不需要重新处理，这部分输入 token 的费用大幅降低。”

14、Vibe Coding 和 Spec Coding 有了解吗？

“Vibe Coding 是 Andrej Karpathy 提出的一个概念，用自然语言告诉 AI 你想要什么，AI 生成代码，你不逐行审查，跑通了就行。遇到报错就把报错信息丢给 AI，让它自己修。整个过程需要你在古法编程时期积累一定量的工程思维。”

“Spec Coding 是另一个思路。先写规格说明，比如说需求文档、接口定义、测试用例——然后让 AI 按规格实现。每一步都有明确的验收标准，AI 的输出可以对照规格做检查。”

“实际工作中我两个都用。做原型、试新工具、写一次性脚本的时候用 Vibe Coding，快。但做项目核心模块的时候用 Spec Coding，先把方案和接口定义写清楚再让 AI 动手。”

ending

上周六，Apple ID 莫名被锁了，这个账号用了两三年，一直很稳定。

所以刚开始挺难受的，后来情绪释放后反而释怀了：要是 Claude 和 Codex 真不能用，我可能就真的完全切到国产化模型了。

虽然我知道，国产模型和顶级模型还有差距，但依靠我积累的这些经验，我想应该也能满足我的日常工作需求。

更关键的是，还能省点钱。

现在每天看着自己的 Codex 还有 90% 多的额度，蛮可惜的，总想把它蹬完，但蹬完又很累，需要一直盯着 Codex 不停去调整。

希望不管是国产模型，还是国产 Agent，包括国内的所有公司，都能越来越好。这样我们打工人才会有一个相对稳定的工作环境。

加油吧，我们下期见。