从Lilian Weng的Agent框架图问世到现在，已经过去整整一年了。这一年里，不少大厂和初创团队都前赴后继，试图把Agent真正落地到业务场景中。过程中踩过的坑、积累的经验，其实非常宝贵。最近读到几篇LinkedIn团队的实践总结，干货满满，忍不住想和大家分享一下。

01 总体概览

先看一个具体的场景，感受一下这套系统是怎么运转的。

假设你正在刷LinkedIn的动态，突然看到一条关于“设计可访问性”的有趣帖子。帖子旁边，系统贴心地提供了几个入门级问题，吸引你深入了解。你出于好奇，点了一个问题：“在科技公司中，可访问性如何推动业务价值？”

接下来，系统在幕后做了三件事：

• 选择最合适的Agent：系统分析你的问题，判断出这是关于“科技公司”和“可访问性”的，于是将它派发给专门处理这类查询的Agent。
• 信息搜集：Agent开始工作，通过调用内部API和Bing搜索，寻找能说明设计可访问性如何提升商业价值的具体案例。
• 生成回复：素材搜集完毕，Agent整合信息，生成一个既有案例又有数据支撑的回答。为了避免大段文字显得枯燥，系统还会调用内部API，附上相关文章链接或人物简介，增加互动性。

你可能会接着问：“那我该怎么转行到这个领域？”这时，系统会无缝转移到另一个专门负责职业规划的Agent。整个过程只需几次点击，就能把一个话题聊透，获得真正可操作的见解。

这一切都离不开大型语言模型（LLM）的快速发展。但光有模型还不够，真正落地过程中的挑战和经验，才是最有价值的部分。

02 哪些部分相对轻松

整体设计

Figure1. 处理用户查询的简化流程。KSA代表“知识共享”Agent，是可以处理用户查询的数十个Agent之一

你可能已经看出来了，这套系统采用了检索增强生成（RAG）模式，这在生成式AI应用中算是标准配置。有意思的是，搭建这套基本流程比想象中要快得多。团队只用了几天时间，就搞定了核心框架：

• 路由：判断查询是否在服务范围内，并决定交给哪个Agent处理。比如，有的Agent擅长工作评估，有的擅长公司分析，还有的专门负责提取帖子要点。
• 检索：这一步重在“召回”。Agent需要决定调用哪些服务（比如人员搜索、Bing API等），以及如何调用。
• 生成：这一步则重在“精度”。它需要从检索到的庞杂数据中筛选、加工，最终形成高质量的回复。

由于路由和检索这两个环节带有明显的分类性质，调整起来反而比较顺手。团队专门为它们创建了开发集，通过提示工程和内部模型进行优化。但生成阶段就完全是另一回事了。这里遵循典型的二八原则：前80%的工作可以快速完成，但最后20%却要投入大量精力。当产品对回答质量的要求是99%以上都必须“很好”时，即便用上最先进的模型，每提升1%都可能需要绞尽脑汁。

团队在实践中摸索出一些有效做法：

• 固定了三步流程，不轻易改动
• 路由和检索用小型模型，生成则交给更大的模型
• 通过内存数据库支持的基于嵌入的检索（EBR），作为低成本的微调手段，直接把响应示例融入提示中
• 针对每个步骤设定专门的评估流程，尤其是在路由和检索阶段

开发速度

为了在多团队协作中快速推进，团队一开始把任务分配给不同的人，开发各种独立的Agent，比如常规知识、职位评估、摘要提取等。

但这带来了一个明显的副作用。任务并行确实提升了速度，却导致系统变得碎片化。当用户和助手的多轮对话可能由不同的模型、提示或工具管理时，要保持统一的用户体验就变得非常困难。

解决方案是采用一种简单的组织结构：

• 一个小型“横向”工程小组，负责处理公共组件和整体体验。具体包括：托管产品的服务、评估/测试工具、所有垂直部门共用的全局提示模板（比如Agent的全球身份、对话历史、越狱防御等）、以及共享的UX组件和服务器驱动的UI框架。
• 几个拥有自主权的“垂直”工程小组，比如负责个性化帖子摘要的、职位适配评估的、面试技巧的。

成功的经验可以总结为：分而治之，同时严格限制Agent的数量；对多轮对话进行集中评估；共享提示模板、UX设计模板、工具和仪表盘。

03 真正的难点在哪

评估

评估AI回答的质量，远比想象中要难。挑战主要来自三个方面：制定标准、扩展标注、自动评估。

• 制定标准是第一个坎。以职位评估为例，单纯告诉用户“你不适合这个职位”没什么用。回答既要基于事实，还得有同理心。对那些想转行但能力尚有不足的用户，要帮他们看清能力差距和下一步该做什么。要保证这些细节的一致性是确保评估得分统一的关键。
• 扩展数据标注是第二步。刚开始，团队所有人都参与评估（产品、工程、设计），但很快发现需要更系统的方法。标注者既要保持一致性，也要具备多样性。团队的语言学专家开发了工具和流程，每天能评估多达500个对话，收集包括总体质量评分、幻觉发生率、负责任AI遵守情况、逻辑连贯性、风格等多个维度的数据。这些数据成为洞察趋势、优化提示词、确认产品上线前准备程度的重要依据。
• 自动评估是理想状态，但实现起来挑战重重。在没有自动化工具时，工程师只能靠肉眼和有限样本测试，学习评估标准通常需要一天以上。团队正在开发基于模型的评估工具来加速实验，在检测幻觉方面取得了一些进展，但过程并不容易。

Figure2. 评估步骤。工程师执行快速、粗略的评估以获得方向性指标。标注员提供更细化的反馈，但周转时间约需1天。成员是最终评判者，提供规模优势，但某些指标的单次更改可能需要3天以上。

团队目前正在做的：开发一个端到端的自动评估流程，加快迭代速度。

调用内部API

LinkedIn内部拥有大量关于个人、公司、技能和课程等的独特数据。这些数据是打造差异化产品的核心，但LLM并不了解它们，无法直接用于推理和生成。标准做法是建立RAG流程，通过调用内部API，将返回结果嵌入到LLM的提示中，作为生成回答的背景信息。

这些数据通过不同微服务的RPC API在内部公开，对程序化调用很方便，但对LLM来说就不太友好。为此，团队为这些API创建了“技能”包装。每个技能都包含：

• 对人类（也是LLM）友好的API功能描述及使用时机
• 调用RPC API的配置（端点、输入架构、输出架构等）
• LLM友好的输入和输出架构（包括原始类型值、JSON模式风格的描述）
• 将LLM友好架构与实际RPC架构进行映射的业务逻辑

这样一来，LLM就能执行各种产品相关的操作，比如查看个人资料、搜索文章/人员/职位/公司，甚至查询内部分析系统。这套技术也用于调用非LinkedIn的API，比如Bing搜索和新闻。

Figure3. 使用技能调用内部API

团队设计了提示词，要求LLM决定用什么技能来解决特定工作（通过规划选择技能），然后输出调用技能的参数（函数调用）。由于参数必须与输入模式匹配，所以要求LLM以结构化的方式输出。大多数LLM是通过YAML和JSON来结构化输出的。选择YAML，是因为它更简洁，消耗的Token更少。

一个棘手的挑战是，虽然大部分时间LLM的格式都正确，但大约10%的情况下会出错。最常见的是输出数据不符合架构，甚至不是有效的YAML。这些错误对人类来说很容易识别，但解析代码就会出问题。由于错误率太高，不得不认真解决。

常规方法是检测到错误后重新提示LLM，要求其在额外指导下纠正。虽然有效，但会增加延迟和GPU资源消耗。为了规避这些限制，团队最终开发了一个内部的防御性YAML解析器。通过分析各种数据负载，确定LLM常见的错误类型，然后编写代码在解析前进行检测和修复。同时，在提示词中嵌入关于这些常见错误的提示，提高修复的准确性。最终，将错误率降低到了约0.01%。

团队正在做的：开发一个统一的技能注册表，用于动态发现和调用API/Agent，并将其打包为LLM友好型技能，供整个生成式AI产品使用。

质量稳定性

团队在第一个月内就完成了基本体验的80%，但接下来的四个月都在努力完善、调整，试图达到95%的完整目标。还是低估了检测和减少幻觉的难度，也低估了质量分数的提升速度——开始时直线上升，很快就趋于平稳。

对于能容忍一定错误的产品体验来说，用生成式AI构建应用会让人感觉很爽。但它也带来了难以实现的期望：初期的快速进展会让人产生“很快就能成功”的错觉，而后续每提升1%都异常缓慢，这种感觉确实挺让人沮丧。

构建这样的助手，感觉更像是在调整专家系统的规则，而不是进行更有原则的机器学习。因此，虽然评估变得越来越复杂，但“训练”主要依赖的是prompt engineering，这与其说是科学，不如说是艺术。

团队正在做的：微调大型语言模型（LLM），让流程更依赖数据驱动。

容量与延迟

容量和用户感知到的延迟，始终是团队关注的重点。几个关键点包括：

• 质量与延迟：像思维链（CoT）这样的技术，在提高质量和减少幻觉方面效果显著，但需要消耗用户看不见的Token，因此增加了感知延迟。
• 吞吐量与延迟：运行大型生成模型时，随着使用率增加，首次生成Token的时间（TTFT）和Token之间的时间（TBT）通常会增加。TBT有时会线性增长。如果愿意牺牲这两个指标，获得2倍或3倍的每秒Token数（TPS）并不罕见，但团队最初必须严格控制这些指标。
• 成本：GPU集群既难获得又成本高昂。一开始甚至要设定测试产品的时间表，因为会消耗过多Token，影响开发人员工作。
• 端到端流式处理：完整的回答可能需要几分钟，所以团队让所有请求都进行流式处理，以减少感知延迟。更重要的是，实现了整个流程的端到端流式处理。比如，LLM响应决定调用哪些API会被逐步解析，参数准备好后立即触发API调用，不等完整的LLM响应。最终合成的回应也通过实时消息基础设施流式传输到客户端，一路进行增量处理。
• 异步非阻塞管道：由于LLM调用耗时较长，团队通过构建完全异步的非阻塞管道来优化服务吞吐量，避免因I/O阻塞而浪费资源。

这些方面有时会相互影响。例如，最初只限制了TTFT，因为它直接影响用户延迟。但后来为了解决幻觉问题，在提示中引入思维链时，忽略了TBT会带来更大的影响。任何“推理”Token都会增加用户延迟（200个Token的推理步骤，即使TBT增加10毫秒也意味着额外2秒的延迟）。这导致一个公开发布突然触发超时警报，团队迅速增加了容量才缓解。

团队正在做的：将更简单的任务转移到内部微调模型；为LLM部署提供更可预测的基础设施；减少每一步浪费的Token。

04 总结

说了这么多，不如让产品自己来证明吧。