办公智能体套件开发指南：从WorkBuddy到CodeBuddy的架构设计与落地实践

1. 办公智能体套件到底在解决什么问题

1.1 从“对话框”到“工作台”的认知转变

大部分人第一次接触智能体，都是从网页对话框开始的。你问一句，它答一句，聊得挺热闹，但关掉页面之后，工作还是那些工作，文档还是那些文档。这种形态的智能体本质上是个“问答机器”，它没有真正进入你的工作流。

办公智能体套件要解决的核心问题，恰恰是把这个“问答机器”变成“工作台”。什么意思？就是智能体不再只是一个你主动去访问的页面，而是嵌入到你日常办公的各个环节里——写代码的时候它在IDE里，写文档的时候它在编辑器里，处理邮件和日程的时候它在协作工具里。它不是一个独立的工具，而是一层能力，覆盖在你已有的工作流之上。

这个转变听起来简单，但背后的工程复杂度差了好几个量级。对话框形态的智能体，只需要处理“输入-推理-输出”这一个链路。而办公套件形态的智能体，需要处理的是：如何感知当前上下文（你在哪个应用、操作什么文件、处于什么任务阶段）、如何调用外部工具（读写文件、执行命令、访问API）、如何管理多轮任务的状态（一个任务可能跨越几十分钟甚至几天）、以及如何在不同应用之间保持一致的体验。

我自己的体会是，当你把智能体从对话框里“放出来”，让它真正能碰到你的文件、你的代码、你的日程表的时候，它的价值才会指数级放大。但与此同时，你需要考虑的边界条件也成倍增加。

1.2 套件化的意义：为什么不是单个工具

很多人会问：我直接用某个单独的AI编程助手不就行了吗，为什么要搞一套“套件”？

这个问题我在实际项目里被问过很多次。答案其实不复杂：因为真实的工作场景从来不是单一维度的。一个开发者的一天可能是这样的——早上先看邮件和日程，然后写代码，中间穿插写技术方案文档，下午开会讨论，会后整理会议纪要并分配任务。如果每个环节都需要切换到一个不同的AI工具，那这个切换成本本身就抵消了AI带来的效率提升。

套件化的核心价值在于上下文连续性。你在写代码时智能体积累的项目理解，能不能带到写文档的环节？你在会议中讨论的技术方案，能不能直接变成代码任务？这些跨场景的衔接，单点工具做不到，只有套件级别的整合才能实现。

另一个容易被忽略的点是统一的管理和治理。企业级场景下，IT部门需要知道：哪些智能体在被使用、它们能访问哪些数据、产生了什么操作记录、成本如何控制。如果每个员工自己装一堆不同的AI工具，这些管理需求根本无从谈起。套件化提供的统一管控能力，是企业愿意买单的关键原因之一。

1.3 行业解决方案的差异化逻辑

“行业解决方案”这个词听起来很虚，但落到实际场景里，差异是实打实的。

举个具体的例子：法律行业的文档审阅和制造业的设备巡检报告，表面上都是“文档处理”，但智能体需要的能力完全不同。法律文档审阅需要极高的精确度和引用溯源能力，一个条款引用错了可能造成严重后果；而设备巡检报告更看重结构化信息提取和多模态理解（比如从照片中识别设备状态）。

这就是为什么套件需要提供行业解决方案层——底层的智能体框架和工具调用能力是通用的，但上层的提示词模板、工具集配置、知识库接入方式、输出格式规范，需要针对不同行业做深度定制。通用的智能体平台解决的是“能不能做”的问题，行业解决方案解决的是“做得好不好、能不能直接用”的问题。

我在实际落地中观察到的一个规律是：越是垂直的场景，对预置能力的要求越高。一个通用智能体可能只能完成60分的任务，但一个针对特定行业调优过的解决方案，可以直接做到85分以上。这25分的差距，往往就是“能用”和“好用”的分界线。

2. 核心组件拆解：WorkBuddy与CodeBuddy的定位差异

2.1 WorkBuddy：面向通用办公场景的智能体工作台

WorkBuddy的定位是“工作台”，这个词选得很准确。它不是某个单一功能的工具，而是一个承载多种办公任务的平台。

从实际使用角度来看，WorkBuddy的核心能力可以拆成几个层面。最基础的是任务理解与拆解——你给它一个相对模糊的指令，比如“帮我整理一下这周的客户反馈并生成周报”，它需要先理解这个任务包含哪些子步骤：收集反馈数据、分类归纳、提取关键问题、生成结构化报告。这个拆解过程的质量，直接决定了最终输出的可用性。

往上一层是工具调用与执行。WorkBuddy需要能够操作文件系统、访问协作平台、调用API接口。比如生成周报这个任务，它可能需要读取共享文档中的反馈记录、调用数据分析接口做统计、最后把生成的报告写入指定目录。这些操作涉及不同的系统，需要统一的工具调用框架来管理。

再往上是多轮任务管理。很多办公任务不是一次对话就能完成的。比如“帮我安排下周的客户会议”这个任务，可能涉及查日程、发邀请、等确认、调整时间等多个轮次，中间可能间隔数小时甚至数天。WorkBuddy需要维护这些任务的状态，在合适的时机主动推进。

我实际使用中感受最深的一点是，WorkBuddy的“自定义指令”功能是真正提升效率的关键。你可以把常用的工作流固化成指令模板，比如“每周一早上自动汇总上周的销售数据并生成简报”，设置好之后它就会按计划执行。这个功能把智能体从“被动响应”变成了“主动服务”，体验上的差异非常大。

2.2 CodeBuddy：深度嵌入开发流程的编程智能体

CodeBuddy和WorkBuddy虽然同属一个套件，但设计哲学有明显差异。CodeBuddy更强调深度嵌入——它不是让你去一个独立界面里写代码，而是直接融入你已有的IDE环境。

这个选择背后的逻辑很清晰：开发者的注意力是最宝贵的资源。任何需要离开IDE去另一个窗口的操作，都会打断心流状态。CodeBuddy通过IDE插件的形式，让智能体能力直接出现在代码编辑器里——你选中一段代码，右键就能让智能体解释、重构、生成测试；你在写代码时，它可以根据上下文自动补全；你遇到报错时，它可以直接分析错误栈并给出修复建议。

CodeBuddy的另一个核心能力是大项目理解。小项目里，智能体只需要看当前文件就能给出有用的建议。但真实的企业项目往往有几十万行代码、数百个文件、复杂的模块依赖关系。CodeBuddy需要能够索引整个代码库，理解模块之间的调用关系，才能给出准确的建议。这个索引和理解的工程挑战很大，但也是区分“玩具”和“工具”的关键分水岭。

快捷键的设计也值得一说。CodeBuddy提供了一套快捷键体系，让常用操作可以一键触发。比如快速唤起对话、快速应用建议、快速切换模型等。这些看似小的设计，在实际高频使用中带来的效率差异非常明显。我自己的习惯是把手放在键盘上不离开，所有操作都通过快捷键完成，这样思路不会断。

2.3 两者如何协同：套件的整合价值

WorkBuddy和CodeBuddy不是孤立存在的，它们之间的协同才是套件真正的价值所在。

一个典型的协同场景是这样的：产品经理在WorkBuddy里整理了一份需求文档，开发者在CodeBuddy里直接引用这份文档作为上下文来生成代码框架，代码写完后CodeBuddy自动生成技术文档回写到WorkBuddy的工作台，测试人员再基于这些文档在WorkBuddy里创建测试用例。整个链路中，上下文是连续的，不需要人工在不同工具之间复制粘贴。

这种协同的实现依赖于套件层面的统一上下文层。每个智能体产生的中间产物——文档、代码、任务状态——都存储在一个共享的上下文空间里，其他智能体可以按权限访问。这个设计让“套件”不只是一个产品打包的概念，而是真正产生了1+1>2的效果。

从管理角度看，套件还提供了统一的用量监控和权限控制。管理员可以看到每个智能体的调用次数、Token消耗、操作记录，也可以设置不同角色的访问权限。比如财务部门的智能体不能访问代码仓库，开发部门的智能体不能读取人事数据。这些治理能力在单点工具时代是很难实现的。

3. 智能体开发的核心技术点与实操要点

3.1 智能体框架选型：从LangChain到更轻量的方案

聊到智能体开发，绕不开框架选型这个话题。目前市面上主流的方案大致分几类，我结合自己的使用经验做个对比。

LangChain是最早流行起来的框架，生态最全，几乎什么都有现成的集成。但它的抽象层数比较多，调试的时候经常需要深入好几层才能找到问题所在。LangGraph是LangChain团队推出的图结构编排方案，适合需要复杂状态管理的场景，比如多轮对话、条件分支、循环执行等。它的核心思路是把智能体的执行流程建模成一张图，节点是操作，边是流转条件。这个模型很强大，但学习曲线也比较陡。

另一类方案更轻量，比如直接基于大模型API做函数调用（Function Calling），自己管理对话历史和工具调用逻辑。这种方式灵活度最高，代码量也不大，适合对框架没有强依赖、希望完全掌控执行流程的场景。缺点是需要自己处理很多细节，比如错误重试、超时控制、并发管理等。

我的建议是：如果是做原型验证或者简单的单轮任务，直接用API加函数调用就够了，没必要引入重框架。如果任务涉及复杂的状态流转、多智能体协作、或者需要长期维护，那LangGraph这类图编排框架会更合适。选型的核心原则是匹配任务复杂度，不要为了用框架而用框架。

3.2 工具调用与函数注册的实操细节

工具调用是智能体从“会说”到“会做”的关键跨越。但实际落地时，工具注册和管理有很多细节需要注意。

首先是工具描述的写法。大模型是根据工具的名称和描述来决定是否调用、如何调用的。描述写得好不好，直接影响调用准确率。我踩过的坑是：描述写得太简略，模型不知道什么时候该用这个工具；描述写得太复杂，模型又容易混淆不同工具的边界。比较好的做法是：用一句话说清楚工具的功能，再用一两句话说明使用场景和限制条件。

其次是参数校验和错误处理。模型生成的参数不一定总是合法的，可能类型不对、可能缺少必填项、可能超出取值范围。工具执行前必须做严格的参数校验，执行后要有清晰的错误返回。错误信息也要设计好——不能只返回“执行失败”，要告诉模型具体哪里错了、应该怎么修正。这样模型才有机会自我纠正。

还有一个容易被忽略的点是工具的数量控制。一次注册太多工具，模型的调用准确率会下降，因为它需要在更多选项里做选择。我的经验是，单个智能体注册的工具数量控制在10-15个以内比较合适。如果确实需要更多工具，可以考虑分层注册——先让模型选择工具类别，再在类别内选择具体工具。

3.3 提示词工程在办公场景的特殊考量

办公场景的提示词工程和通用对话场景有很大不同，核心差异在于对准确性和一致性的要求更高。

通用对话场景下，回答有点偏差用户可能不太在意。但办公场景下，比如生成一份合同摘要，如果关键条款漏了或者理解错了，后果可能很严重。所以办公场景的提示词需要更强调约束条件和输出格式。

我常用的一个模式是“角色+任务+约束+格式”四段式。角色定义智能体的专业身份（比如“你是一位有十年经验的法务顾问”），任务描述具体要做什么，约束列出不能做什么和必须做什么，格式规定输出的结构。这个模式看起来简单，但实际效果比随意写的提示词稳定很多。

另一个关键点是少样本示例（Few-shot）的设计。在办公场景里，给一两个高质量的输入输出示例，比写一大段描述性文字有效得多。示例要覆盖典型场景和边界情况，让模型通过模仿来理解期望的输出风格。

还有一个实操技巧是输出格式的强约束。如果下游系统需要解析智能体的输出，最好要求它输出JSON格式，并在提示词里给出明确的Schema定义。这样即使模型的理解有偏差，至少格式是对的，下游系统不会直接崩溃。

4. 从零搭建一个办公智能体的完整流程

4.1 需求拆解与能力边界定义

动手写代码之前，最重要的一步是搞清楚：这个智能体到底要解决什么问题，以及它不应该做什么。

我见过很多失败的智能体项目，根本原因不是技术不行，而是一开始的需求就没定义清楚。比如“帮我处理邮件”这个需求就太模糊了——是自动分类？自动回复？还是提取待办事项？不同的理解对应完全不同的技术方案。

我的做法是先把需求拆成输入-处理-输出三个环节。输入是什么？邮件正文、附件、发件人信息？处理要做什么？分类、摘要、提取关键信息？输出到哪里？写入待办列表、生成回复草稿、还是发送通知？把这三个环节定义清楚，技术方案基本就确定了。

同时要明确能力边界。哪些事情智能体可以做，哪些必须人工确认？比如自动分类邮件可以全自动，但自动发送回复就必须加人工审核环节。这个边界定义不只是技术问题，更涉及风险控制。我的原则是：读操作可以放开，写操作必须谨慎。智能体可以自由读取和分析数据，但涉及修改、删除、发送等操作时，要么加确认步骤，要么限制在低风险范围内。

4.2 环境准备与基础配置

环境准备这一步看起来简单，但实际踩坑不少。我以常见的Python技术栈为例，把关键步骤和注意事项过一遍。

首先是Python版本的选择。建议用3.10或3.11，这两个版本对异步支持和类型系统的完善度比较好，而且主流智能体框架的兼容性也最好。3.12虽然更新，但部分依赖库可能还没跟上。

虚拟环境是必须的，这个不用多说。我习惯用venv，轻量够用。创建好之后，核心依赖通常包括：大模型SDK（比如OpenAI或国内模型的SDK）、HTTP客户端（httpx或requests）、数据处理库（pydantic用于数据校验）、以及可选的智能体框架。

python -m venv agent-env source agent-env/bin/activate # Linux/Mac pip install openai httpx pydantic python-dotenv

API密钥的管理要用环境变量，绝对不要硬编码在代码里。用python-dotenv加载.env文件是个好习惯，记得把.env加入.gitignore。

from dotenv import load_dotenv import os load_dotenv() api_key = os.getenv("LLM_API_KEY") base_url = os.getenv("LLM_BASE_URL")

注意：如果你在团队里共享代码，确保.env.example文件里只放变量名不放真实值，真实值通过安全的渠道分发。

4.3 核心逻辑实现：一个邮件处理智能体的完整代码

下面用一个具体的例子把核心逻辑串起来。假设我们要做一个邮件处理智能体，功能是：读取未读邮件、分类、提取待办事项、生成摘要。

先定义工具函数。工具函数的设计原则是单一职责——每个函数只做一件事，参数和返回值都要有明确的类型标注。

from pydantic import BaseModel, Field from typing import Literal class EmailInput(BaseModel): email_id: str = Field(description="邮件的唯一标识符") class EmailCategory(BaseModel): category: Literal["urgent", "todo", "info", "spam"] = Field( description="邮件分类：紧急、待办、参考信息、垃圾邮件" ) confidence: float = Field(description="分类置信度，0到1之间") reason: str = Field(description="分类理由的简要说明") def classify_email(email_content: str) -> EmailCategory: """对邮件内容进行分类""" # 实际实现中这里会调用大模型 ...

然后是智能体的主循环。核心逻辑是：获取未读邮件列表，对每封邮件依次执行分类、提取、摘要，最后汇总结果。

def process_inbox(max_emails: int = 20): emails = fetch_unread_emails(limit=max_emails) results = [] for email in emails: category = classify_email(email.content) todos = extract_todos(email.content) summary = generate_summary(email.content) results.append({ "id": email.id, "subject": email.subject, "category": category.category, "todos": todos, "summary": summary }) return results

这个结构看起来简单，但实际运行时需要考虑很多工程细节。比如错误处理——某封邮件处理失败了不能影响其他邮件；速率限制——调用大模型API有频率限制，需要加退避重试；并发控制——串行处理太慢，但并发太高又容易触发限流。

我的做法是用asyncio做异步处理，配合信号量控制并发数，再加一个简单的重试装饰器。

import asyncio from tenacity import retry, stop_after_attempt, wait_exponential @retry(stop=stop_after_attempt(3), wait=wait_exponential(min=1, max=10)) async def call_llm_with_retry(prompt: str) -> str: # 带重试的大模型调用 ... async def process_emails_concurrently(emails, max_concurrent=5): semaphore = asyncio.Semaphore(max_concurrent) async def process_one(email): async with semaphore: return await process_single_email(email) tasks = [process_one(e) for e in emails] return await asyncio.gather(*tasks, return_exceptions=True)

4.4 效果验证与迭代优化

智能体跑起来只是第一步，真正的功夫在迭代优化上。

评估集的构建是优化的基础。你需要准备一批标注好的测试数据——比如100封已经人工分类好的邮件，用它们来测试智能体的分类准确率。没有评估集，优化就是盲人摸象，你不知道改动提示词之后效果是变好了还是变差了。

评估指标要根据任务类型来定。分类任务看准确率和召回率，摘要任务可以用ROUGE或BERTScore，提取任务看字段级别的精确匹配率。对于办公场景，我还会加一个人工抽检环节——随机抽20%的输出让真实用户评分，因为自动指标有时候和人的感受不一致。

迭代的方向通常有几个：调整提示词（最常见）、更换模型（效果提升明显但成本增加）、增加少样本示例（对格式一致性帮助大）、优化工具描述（提升调用准确率）。每次只改一个变量，改完跑评估集，对比指标变化。这个流程听起来笨，但最可靠。

我自己的经验是，第一版智能体通常只能达到60-70分的水平，经过3-5轮迭代能到85分左右，再往上就需要更精细的调优和更多的领域数据了。从85分到95分花的精力，可能比从0到85分还多。所以实际项目中要设定合理的期望值，不要追求完美。

5. 常见问题与排查技巧实录

5.1 智能体“不听话”的典型原因与解法

智能体不按预期执行，这是最高频的问题。根据我的排查经验，原因通常集中在几个方面。

工具描述不清晰是最常见的原因。模型不知道某个工具具体什么时候该用，就会要么不用，要么乱用。解法是把工具描述写得更具体，明确使用场景和限制条件。比如不要写“查询数据”，要写“根据用户ID查询订单历史，仅在用户明确提到订单相关问题时使用”。

提示词冲突是第二个高频原因。系统提示词里说“回答要简洁”，但用户示例里又展示了很长的回答，模型就困惑了。解法是检查所有提示词和示例，确保它们传达的期望是一致的。

上下文过长也会导致行为异常。当对话历史或文档内容超出模型的上下文窗口时，早期的指令可能被“挤出去”，模型就忘了最初的约束。解法是做好上下文管理——该截断的截断，该摘要的摘要，关键指令放在靠前的位置。

模型能力边界也是要考虑的因素。有些任务就是超出了当前模型的能力范围，比如需要精确数学计算、需要实时信息、需要多步复杂推理。这种情况下，要么换更强的模型，要么把任务拆解成更小的步骤，要么引入外部工具来辅助。

5.2 性能瓶颈的定位与优化

智能体响应慢，用户体验就差。性能问题通常出在几个环节。

大模型调用延迟是大头。不同模型的响应速度差异很大，同一个模型在不同负载下速度也不一样。优化手段包括：选用更快的模型处理简单任务、对响应做流式输出让用户先看到部分结果、对常见问题做缓存避免重复调用。

工具执行延迟也经常被忽略。比如读写大文件、调用外部API、查询数据库，这些操作可能比模型推理还慢。解法包括：异步执行不阻塞主流程、对查询结果做缓存、批量操作合并请求。

串行处理是架构层面的问题。如果每个步骤都等上一步完成才开始，总耗时就是所有步骤之和。改成并行处理后，总耗时取决于最慢的那个步骤。当然，并行也要注意依赖关系——有数据依赖的步骤不能并行。

我常用的一个诊断方法是加时间戳日志，记录每个环节的开始和结束时间。跑几次之后就能看出瓶颈在哪里。优化的时候优先解决占比最大的那个环节，投入产出比最高。

5.3 安全与权限管理的避坑指南

办公场景的智能体直接接触企业数据，安全和权限管理不能马虎。

最小权限原则是基础。智能体只应该拥有完成其任务所必需的最小权限。比如一个只负责生成周报的智能体，不应该有删除文件的权限。这个原则听起来简单，但实际配置时经常被忽略——为了图方便给了过大的权限，埋下安全隐患。

敏感数据脱敏是另一个关键点。智能体在处理数据时，可能接触到手机号、身份证号、银行账号等敏感信息。这些信息在传给大模型之前应该做脱敏处理，用占位符替换真实值，等模型输出后再还原。这样即使模型端出现数据泄露，敏感信息也不会暴露。

操作审计是事后追溯的依据。智能体的每一次工具调用、每一次数据访问都应该记录日志，包括时间、操作类型、操作对象、执行结果。这些日志不仅用于安全审计，也是排查问题的宝贵资料。

人工确认环节在高风险操作前必须保留。什么是高风险操作？发送邮件、修改数据库、调用支付接口、删除文件——这些操作一旦出错后果严重，应该要求人工确认后再执行。确认环节会增加一些操作步骤，但相比出错后的修复成本，这个代价是值得的。

5.4 常见问题速查表

6. 行业解决方案的落地经验与扩展思路

6.1 销售场景：从线索挖掘到跟进提醒

销售场景是我见过智能体落地效果最明显的领域之一。核心原因在于销售工作中有大量重复性的信息处理任务，而且这些任务的规则相对明确，适合智能体发挥。

一个典型的销售智能体工作流是这样的：从多个渠道（邮件、表单、聊天记录）收集线索信息，自动做初步筛选和评分，把高价值线索推送给对应的销售，同时生成跟进建议和话术模板。销售跟进之后，智能体根据跟进记录自动更新线索状态，并在合适的时间点提醒销售进行下一次跟进。

这个流程中，智能体替代的是“信息收集-整理-提醒”这一段的重复劳动，而“判断-沟通-谈判”这些需要人际互动和复杂判断的环节仍然由人来做。这个分工很关键——智能体做它擅长的（信息处理），人做人擅长的（关系建立和决策）。

实际落地时的一个关键点是线索评分模型的可解释性。销售需要知道为什么这个线索被评了高分，才能有针对性地跟进。如果智能体只给一个分数不说理由，销售就不信任它。所以输出中要包含评分依据，比如“该线索来自行业头部企业、预算明确、时间紧迫，综合评分85分”。

6.2 研发场景：代码审查与文档自动化

研发场景的智能体落地，CodeBuddy这类工具已经覆盖了编码辅助的部分。但除了写代码，研发流程中还有大量其他环节可以智能化。

代码审查是一个典型场景。智能体可以在代码提交时自动检查：是否符合团队的编码规范、是否有明显的安全漏洞、是否有性能隐患、测试覆盖率是否达标。这些检查规则明确、重复性高，非常适合智能体来做。当然，最终的审查决定还是由人来做，智能体只是把明显的问题先过滤一遍，减少人工审查的负担。

文档自动化是另一个高价值场景。研发过程中产生的文档很多——技术方案、接口文档、变更记录、部署说明。这些文档的初稿可以由智能体根据代码变更和提交记录自动生成，开发者只需要审核和补充。我实际用下来，文档初稿的生成能节省60%以上的时间，而且因为是从代码直接生成的，准确度比人工回忆着写要高。

还有一个有意思的场景是故障排查辅助。当线上出现告警时，智能体可以自动收集相关的日志、监控指标、最近的代码变更记录，汇总成一个排查报告，并给出可能的根因方向。这不能替代工程师的判断，但能大幅缩短信息收集的时间。

6.3 扩展思路：从单点智能体到多智能体协作

单个智能体的能力是有上限的。当任务复杂度继续增加时，多智能体协作是自然的演进方向。

多智能体协作的核心思路是：把复杂任务拆解成多个子任务，每个子任务由一个专门的智能体负责，智能体之间通过消息传递来协调。比如一个“产品发布”任务，可以拆成市场分析智能体、文案生成智能体、设计稿审核智能体、发布计划智能体等，它们各自负责自己的领域，通过一个协调者智能体来统筹。

这种架构的优势是专业化和可扩展性。每个智能体只需要关注自己的领域，提示词和工具集都可以针对性地优化。需要增加新能力时，只需要增加一个新的智能体，不需要改动已有的。缺点是协调复杂度增加——智能体之间的通信可能出错、可能死锁、可能产生冲突，需要额外的机制来管理。

我实际尝试下来的感受是，多智能体协作目前还处于比较早期的阶段，在简单场景下收益不明显，但在复杂的长流程任务中确实能解决单智能体搞不定的问题。如果你的任务涉及多个专业领域的交叉、需要长时间跨度的协调、或者单个智能体的提示词已经复杂到难以维护，那可以考虑多智能体方案。否则，先把单智能体做好做透，可能是更务实的选择。

6.4 智能体评估与持续改进机制

最后聊一个容易被忽视但非常重要的环节：智能体的评估和持续改进。

很多团队做完智能体上线之后就不管了，结果效果逐渐下降——因为业务在变化、数据在变化、用户期望也在变化。没有持续的评估和改进机制，智能体很快就会从“好用”变成“不好用”。

我的做法是建立一套三层评估体系。第一层是自动指标，每天跑一次评估集，监控准确率、召回率、响应时间等核心指标的变化趋势。第二层是用户反馈，在智能体的输出界面加一个简单的评价按钮，收集用户的满意度评分和文字反馈。第三层是定期人工审查，每周抽一批实际使用记录做深度分析，发现自动指标和用户反馈可能遗漏的问题。

改进的触发机制也很重要。当自动指标连续下降超过阈值、或者用户满意度低于某个水平时，自动触发告警，提醒负责人介入排查。改进之后要重新跑评估集，确认效果恢复才能上线。

这套机制听起来有点重，但实际运行起来大部分是自动化的，人工投入主要在定期审查和改进方案的设计上。相比智能体效果下降带来的业务影响，这个投入是值得的。

我在多个项目里反复验证过一件事：智能体的效果上限取决于模型能力，但效果的下限取决于工程质量和运营水平。一个用中等模型但工程扎实、持续优化的智能体，实际表现往往好过一个用最强模型但疏于维护的智能体。把功夫花在工程和运营上，回报是最稳定的。