企业智能体之旅：为什么评估（Evaluation）是一切的起点

摘要：当企业把 AI Agent 从“演示惊艳的原型”推向“生产可信赖的系统”时，评估（Evaluation）就成了决定成败的关键一环——它既不同于传统软件的单元测试，也不同于单模型 benchmark。本文基于 Amazon 内部构建数千个生产级 Agent 的实战经验，系统拆解 AWS 的 Agent 评估方法论，并给出一套从原型验证到生产就绪的工程实践路径。

01 一、从原型到生产：一道被低估的鸿沟

02 二、为什么传统软件工程方法对智能体失效

03 三、ADLC（Agent Development Lifecycle）：为智能体量身设计的开发生命周期

04 四、企业 Agentic 开发：三类工程实践

05 五、结语：评估是规格说明、是质量门控、是生产监控、也是改进的驱动力

一、从原型到生产：一道被低估的鸿沟

过去一年，AI智能体已经从技术探索进入工程落地阶段。越来越多的企业团队开始构建能够调用工具的 LLM 系统、串联多个 API 的编排流程，以及基于内部知识库的对话助手。

原型验证阶段通常进展顺利——Demo 效果令人满意，业务方反馈积极。然而，当团队尝试将这些系统推向生产时，一个关键问题浮现：它真的准备好上生产了吗？

大多数团队正是在这里遭遇瓶颈。制约因素并非模型能力本身，而是缺少一套工程化的质量评判体系——一套能持续回答”它到底好不好”的方法。

这道鸿沟并非偶然。传统软件拥有单元测试、CI/CD 流水线和明确的通过/失败（pass/fail）标准。AI智能体没有。同样的用户输入，今天跑出一个结果，明天换了模型版本，行为悄悄变了，没有任何报警。开发者甚至无法用一行 assert 语句来验证一个多步推理的过程是否正确。

这本质上是一个工程纪律问题，而非模型能力问题。

本系列共四篇文章，目标是提供一套完整的智能体工程纪律路线图。我们从首先要解决的一件事开始——评估（Evaluation），它是一切其他工程实践的地基：没有评估，团队既不知道自己在哪里，也不知道改了之后有没有变好。

二、为什么传统软件工程方法对智能体失效

软件工程师天然会把 AI智能体当成”另一种软件”来对待：写逻辑、做测试、上 CI/CD。这个直觉很合理，但在智能体身上会系统性地失效。原因有三。

1. 非确定性：测试用例今天通过，明天可能失败

传统软件的测试逻辑很简单：给定输入 A，断言输出是 B。这在智能体身上不成立。

LLM 本质上是概率模型。同样的输入，每次调用的输出在统计分布上是不同的。更反直觉的是，即使把 temperature 设为 0（通常被理解为”最确定性的模式”），输出仍然不能保证完全一致：GPU 浮点运算的非结合性、Mixture-of-Experts 的路由机制、批处理的顺序依赖，都会引入微小但真实的差异。目前没有任何主流模型提供商承诺完全确定性的输出。

由此可见，传统的通过/失败测试框架在这里根本不适用。我们需要的不是断言，而是评估——在一个分布上衡量行为，而不是验证一个确定的结果。

2. 自然语言就是”源代码”：改了 Prompt 就是改了代码

在传统软件里，改代码会留下 Git diff，有代码评审（Code Review），有版本历史，有回滚路径。Prompt 没有这一切。

修改一段系统 Prompt，可能只是在末尾加了一句话，但智能体的行为已经发生了根本性的变化——它可能开始拒绝某类请求，可能改变了工具的调用顺序，可能输出格式悄悄变了。没有任何静态分析工具能提前告诉我们这次修改的影响范围。

因此，每一次 Prompt 变更，都必须有配套的评估来量化影响。没有评估，Prompt 工程就是在黑箱里射击。

3. 依赖会自己动：没有部署任何东西，但智能体的行为变了

传统软件的依赖是锁定的：package.json 里有版本号，升级会发生什么是可预期的。模型是隐式依赖，而且它会自己更新。

模型提供商会定期对模型进行安全微调、能力升级或系统提示调整，通常不会发布详细的 Changelog。结果是：代码库没有任何变动，但某天早上智能体开始对某类问题产生不同的响应——更保守了，或者格式变了，或者工具调用的倾向改变了。如果没有持续的评估基线，这种漂移几乎不可能被及时发现。

以上三点共同指向同一个结论：传统的 CI/CD 和 QA 框架不是为这种系统设计的。我们需要一套新的方法论——一套能在概率性、可变性、隐式依赖这三个条件下持续衡量系统质量的工程体系。这就是接下来要谈的 ADLC。

三、ADLC（Agent Development Lifecycle）：为智能体量身设计的开发生命周期

既然传统 SDLC 对智能体失效，我们需要一套为它量身设计的方法论。业界正在形成共识的框架叫做 ADLC（Agent Development Lifecycle）——它不是对 SDLC 的修补，而是一次完整的重构。

ADLC 是飞轮，不是流水线

传统软件开发是线性的：需求 → 设计 → 开发 → 测试 → 上线。上线是终点，下一个版本从头开始。这套逻辑对智能体不成立，因为智能体在生产环境里运行的每一次对话，都是关于它真实行为的最宝贵数据。

ADLC 是一个持续运转的飞轮，六个环节首尾相连：

定义”好”：在动手构建之前，先确定什么叫成功。这不是一句愿景，而是具体的评估标准、基准数据集。
构建：基于清晰的定义，搭建智能体系统。
评估：用第一步定义的标准，系统性地衡量智能体的行为。
门控上线：评估不只是用来看的，它是上线的通行证。评估指标未达阈值，不部署。
生产观测：智能体上线后，持续追踪它在真实流量下的表现——延迟、成功率、工具调用模式、用户反馈。
挖掘失败案例：从生产 Trace 中找到智能体失败或表现异常的样本，将它们加入评估集，持续迭代。

[图1]

与传统CI/CD 最关键的区别

在传统流水线里，”生产”是流程的终点。在 ADLC 里，生产是飞轮最富价值的输入。

这个转变意义深远。它意味着评估集不是在项目初期一次性定义的静态资产，而是随着生产数据持续生长的动态系统。每一个在生产中暴露的真实失败案例，都比在会议室里预设的测试用例更有价值——因为它来自真实用户，在真实上下文下触发了真实的问题。

还有一条长期价值链值得关注：生产 Trace 可以变成评估数据，评估数据在积累到足够规模后，可以变成微调或蒸馏的训练数据。今天投入可观测性和评估体系的成本，会在未来以模型优化的形式产生复利回报。

定义”好”是第一步，不是上线后的复盘

这个排序看起来显而易见，但在实践中经常被颠倒。很多团队的顺序是：先把 Demo 做出来，上线后用户反馈来了再想怎么衡量好坏。

这往往意味着显著的返工成本。如果上线时没有评估基线，就无法判断下一次改动是变好了还是变坏了。失去的不只是某一次 Prompt 改进的验证能力，而是整个系统迭代的方向感。

ADLC 强制要求把”定义’好'”放在第一位，本质上是在要求团队在开始建造之前，先想清楚验收标准是什么——就像盖楼之前要先出图纸，而不是等楼盖完了再画。

四、企业 Agentic 开发：三类工程实践

理解了 ADLC 这套方法论之后，落地就需要具体的工程实践。亚马逊云科技在大量企业智能体项目中积累的经验，看起来分散，但有一条主线贯穿始终：要么在直接做评估，要么在为评估奠基。

仔细看，这些实践分别回答三个问题：如何把评估本身跑起来、如何让数据持续流入评估系统、以及如何让系统架构上可被评估。三者缺一不可——评估流程是出口，数据是管道，架构是地基。我们按这个逻辑，分三类展开。

4.1 第一类：把评估跑起来

4.1.1 从小做起，先定义”成功”长什么样

很多团队启动智能体项目时，第一个问题是”这个智能体能做什么”。这是个错误的起点。

正确的第一个问题是：我们要解决什么问题？

从问题出发，倒推智能体的边界：它应该处理什么，不应该处理什么。如果在建一个财务分析助手，先只做”查季度收入、计算增长率、生成摘要”这三件事，把它们做可靠了，再扩展。不要从一开始就想把所有场景都覆盖——那只会让 Prompt 越来越复杂，Tool 选择越来越混乱，性能越来越难归因。

启动一个智能体项目，应该产出四个具体交付物，而不仅仅是代码：

智能体应该做什么和不应该做什么的清晰定义。把它写下来，与利益相关者分享，用它来拒绝功能蔓延。
智能体的语气和个性。决定它是正式还是对话风格的，如何问候用户，以及遇到范围外的问题时如何处理。
每个工具、参数和知识源的明确定义。模糊的描述会导致智能体做出错误选择。
期望交互的基准数据集，覆盖常见查询和边缘情况。

最后这一项是关键。基准数据集是整个评估体系的”燃料”——没有它，评估系统无从运转，连”智能体有没有进步”都无法回答。它不是上线后再补的东西，而是启动前就要准备好的基础设施。

以下是三种典型智能体的四个交付物，大家可以对照参考：

智能体类型	智能体定义	语气与个性	工具定义	基准数据集
财务分析智能体	帮助分析师查询各区域（EMEA、APAC、AMER）季度营收数据、计算增长指标、生成高管摘要。不提供投资建议，不执行交易，不访问员工薪酬数据。	专业但不失亲切，以名字称呼用户；主动承认数据局限；数据质量存疑时明确说明置信度；不用没有解释的金融行话。	`getQuarterlyRevenue(Region: EMEA\|APAC\|AMER, quarter: YYYY-QN)` — 返回指定区域和季度的营收数据，单位为百万美元。 `calculateGrowth(currentValue: number, previousValue: number)` — 返回百分比变化。 `getMarketData(Region: string, dataType: revenue\|sales\|customers)` — 获取最新行业指标数据。	50条，包括： – “EMEA 第三季度的营收是多少？” – “和上个季度相比增长了多少？” – “亚太区表现怎么样？” – “CEO 的奖金是多少？”（应拒绝回答） – “对比 2024 年所有区域的表现”
HR 政策助手	回答员工关于休假政策、请假申请、福利注册和公司政策的问题。不访问保密人事档案，不提供法律建议，不讨论个人薪酬或绩效评估。	友好且支持性；使用员工偏好的称呼；保持专业同时平易近人；遇到复杂政策时逐步分解说明；对敏感事项主动提出转接 HR 专员。	`checkVacationBalance(employeeId)` — 返回各类型可用天数 `getPolicy(policyName)` — 从知识库获取政策文件 `createHRTicket(employeeId, category, description)` — 升级复杂问题 `getUpcomingHolidays(year, region)` — 返回公司假期日历	45 条，包括： – “我还有几天假？” – “育儿假政策是什么？” – “我下周能请假吗？” – “为什么我的奖金比预期低？”（应升级处理） – “怎么参加健康保险？”
IT 支持智能体	协助员工处理密码重置、软件访问申请、VPN 故障排查和常见技术问题。不访问生产系统，不直接修改安全权限，不处理基础设施变更。	耐心清晰；避免技术行话；提供分步骤操作说明；移到下一步前确认理解；庆祝小进展（”很好，成功了！”）；需要系统权限时升级给 IT 团队。	`resetPassword(userId, system)` — 触发密码重置流程 `checkVPNStatus(userId)` — 验证 VPN 配置与连通性 `requestSoftwareAccess(userId, software, justification)` — 创建访问申请工单 `searchKnowledgeBase(query)` — 检索排障文档	40 条，包括： – “我登不上邮箱” – “VPN 一直断线” – “我需要访问 Salesforce” – “能给我管理员权限吗？”（应拒绝） – “笔记本连不上 Wi-Fi” – “怎么安装 Slack？”

用这个有限范围构建 PoC，然后用真实用户测试。他们会立即发现没有预料到的问题——智能体可能在日期解析上出错，可能不能很好地处理缩写，或者在问题换一种表达方式时就调用了错误的工具。在 PoC 阶段学到这些，代价是几周时间；在生产阶段学到，代价是信誉和用户信任。

4.1.2 从第一天开始自动化评估

有了基准数据集，下一步是建立自动化评估机制——让它成为开发流程的一部分，而不是上线前临时跑一遍的检查清单。

首先要定义衡量指标。不同类型的智能体，关注点不同：客服智能体看解决率和用户满意度，财务智能体看计算准确性和引用质量，HR 助手看政策准确性和回答完整性。但无论哪种智能体，都要同时追踪两类指标：技术指标（延迟、Token 用量、工具调用准确率）和业务指标（回答是否真的有用）。两者要一起看——延迟低但答案错，没有意义；答案好但成本高到无法商业化，同样是问题。

评估数据集要覆盖三类情况：

同一问题的多种表达：用户不会像 API 文档那样说话，”上季度欧洲收入”和”EMEA Q3 数字”应该触发完全相同的工具调用
应该拒绝或升级人工的查询：边界案例同样需要被评估
有歧义的查询：一个问题可能有多个合理解读，智能体应该如何处理

一个具体的指标体系长什么样？还是用财务分析智能体举例

工具选择准确率：面对”上季度收入”类问题，是否选择了 getQuarterlyRevenue 而不是 getMarketData？目标：≥ 95%
参数提取准确率：是否正确将 “EMEA” 和 “Q3 2024” 映射到对应格式？目标：≥ 98%
拒绝准确率：面对”CEO 奖金是多少”，是否正确拒绝？目标：100%
回答质量：解释是否清晰、没有歧义？用 LLM-as-a-Judge 评估
延迟：P50 低于 2 秒，P95 低于 5 秒
每次查询 Token 用量：平均低于 5,000 tokens

有了这套指标体系，评估就成了可量化的决策依据。比如：把模型从 Claude Sonnet 换成 Claude Haiku，重跑评估发现工具选择准确率从 92% 降到 87%，但 P50 延迟从 3.2 秒降到 1.8 秒——这个数字告诉我们速度的提升是否值得那 5% 的准确率代价，而不是凭感觉拍板。

评估必须嵌入开发流程，而不是一次性工作：改了 Prompt？跑评估。加了新工具？跑评估。换了模型？跑评估。反馈循环必须足够快，让团队在下一次改动之前就知道上一次改动的影响，而不是三个 commit 之后才发现问题。

4.1.3 持续测试与改进

智能体上线，不是测试结束的信号，而是测试场景发生根本变化的节点。

在开发阶段，能测试的是预想到的场景。进了生产，真实用户会用完全没预料到的方式问问题，会触发没有覆盖的边界，会在特定时间、特定上下文下让智能体暴露出新的问题。与此同时，模型提供商的后台更新、外部 API 的行为变化，都会在不知情的情况下影响智能体的表现——这种现象叫静默漂移，它不会报错，只会让质量指标悄悄变差。

应对静默漂移的方法只有一个：持续采样，持续评估。

建议建立这样一套测试机制：

每次变更触发回归测试：改 Prompt、加工具、换模型，任何一次改动都要跑完整的评估套件，确认没有引入回归
生产流量持续采样：从真实用户交互中随机抽取样本，用和离线评估相同的指标体系打分，持续监控质量曲线
漂移检测与自动告警：如果某个关键指标（比如工具选择准确率）在两周内从 92% 悄悄降到 84%，必须有机制捕捉到这个变化并告警
重大更新做 A/B 测试：新版本不要全量上线，先用一部分流量验证，确认指标不差于旧版本再切换

改进循环的正确姿势是：评估 → 找到问题所在 → 修改 Prompt、工具定义或 Retrieval 策略 → 重新评估。注意这里没有”重新训练模型”这一步——对绝大多数企业智能体来说，大部分性能提升来自 Prompt、工具和 Retrieval 层面的优化，而不是换模型或微调。换模型是成本更高、风险更大的选项，应该在穷尽其他手段之后才考虑。

一个实际的改进例子。财务智能体上线后，通过生产采样发现有一类查询的工具选择准确率只有 78%：用户问”欧洲今年整体表现怎么样”，智能体频繁调用了 getMarketData 而不是 getQuarterlyRevenue。根因是工具描述不够精确——getMarketData 的描述里有”market performance”字样，和用户表达高度重合。修改方案：细化两个工具的描述，明确各自的适用场景，加入反例说明。改完重跑评估，准确率回升到 95%。整个循环没有动过一行模型代码。

评估是这套改进循环核心可信的信号源。没有它，团队不知道改动方向对不对，也不知道上线之后系统在哪里悄悄变差了。

4.1.4 先把单个智能体做好，再扩展到多智能体

第一个智能体上线，是一个里程碑。但企业真正的价值，来自于把这套能力在组织内规模化复制——而不是每次构建新智能体都从零开始。

规模化有一个前提：单个智能体的质量基线必须先建立好。

评估的复杂度随智能体数量非线性增长。单个智能体出问题，可以独立定位；多个智能体协作时，一个问题可能来自任何一个环节，也可能来自交接过程本身。如果在没有评估基线的情况下就扩展到多智能体系统，出了问题几乎无从归因——不知道是哪个智能体失败了，也不知道是不是某次改动引入的回归。

正确的顺序是：先为单个智能体建立完整的基准数据集、指标体系和 CI 门控，确认它在自己的职责范围内表现稳定，然后再引入第二个、第三个智能体。每个新智能体都应该继承这套工程基础，而不是等所有智能体都上线后再补。

扩展到组织级别时，需要从项目思维转向平台思维。单个项目团队关心的是”这个智能体能不能用”；平台团队关心的是”整个组织的智能体能不能被统一治理”。这通常意味着：

维护一个经过安全审查的工具目录，新团队直接取用，不重复建设
建立统一的可观测性和评估标准，让不同团队的智能体产出可比较的质量数据
运行跨智能体的集中监控，当某个智能体开始影响成本或质量曲线，平台团队能第一时间发现

生产数据是持续改进的原料。第一版上线时的 50 个基准样本，会随着真实用户交互不断扩充——生产中出现的新边界案例、新失败模式，都应该回流到评估集里。规模化不是建更多智能体，而是建立一套让每个智能体都能持续变好的机制。

规模化不是一步到位的。建议按三阶段推进：

爬行阶段：先在内部小范围试点，核心目标是学习和迭代。这个阶段的失败成本低，错了可以快速改。
行走阶段：把智能体推给受控的外部用户群体，更多用户带来更多反馈和边界案例。此前在可观测性和评估上的投入，在这个阶段开始产生回报。
奔跑阶段：有信心地规模化上线，平台能力让其他团队可以更快构建自己的智能体，组织能力开始形成复利。

4.2 第二类：让数据持续流入评估

从第一天就埋好可观测性

可观测性是经常被推迟的那类工作——”先把功能做出来，上线再说”。这往往意味着显著的返工成本。等到意识到需要它的时候，往往已经有一个行为不透明的智能体跑在生产上，而团队完全不知道它在做什么。

可观测性和评估的关系，是数据管道和分析引擎的关系。可以有世界上最好的评估框架，但如果没有 Trace 数据，在线评估无从采样，生产中的失败案例无从挖掘，整套评估体系就只能在离线数据集上工作，看不见生产里真实发生的事情。

可观测性要覆盖三个层次：

开发者层（调试用）：从第一次测试查询开始，就需要能看到智能体每一步在做什么——模型调用了什么、调用了哪个工具、传了什么参数、推理过程中经历了哪些步骤。当用户报告智能体行为异常，需要能拉出对应的 Trace，逐步还原它当时的决策过程。

平台层（治理用）：谁在用智能体，用了多少 Token，哪个团队的智能体在驱动成本增长，某次事故的完整时序是什么——这些是平台团队和管理层关心的问题。没有这一层的数据，智能体系统的成本和风险就处于黑盒状态。

运营层（SLA 用）：延迟百分位数、错误率、工具调用成功率、用户会话完成率——这些指标决定了能不能对业务承诺 SLA，也是触发告警和自动回滚的依据。

技术实现上，OpenTelemetry 是目前的行业标准。它让模型调用、工具调用、推理步骤全部产生结构化的 Trace，可以导出到现有的观测基础设施——无论是 CloudWatch、Datadog、Dynatrace，还是专门针对 LLM 的 LangSmith、Langfuse。关键原则是：从第一天就接入，不要等功能稳定之后再补。

一个实际的场景说明为什么顺序很重要。假设财务智能体在内测阶段没有接入 Trace，只靠用户反馈判断问题。上线三周后，用户开始投诉”查询很慢，有时候还答错”。没有 Trace，团队只能逐一排查：是模型推理慢？是数据库查询慢？是外部 API 出了问题？四天之后才定位到根因——一个外部数据 API 在静默更新后返回格式发生了变化，智能体拿到了格式错误的数据，还继续用它回答问题。

如果从第一天就接入了 OpenTelemetry Trace，这个问题会在第一天就暴露：Trace 会清楚地显示那条查询耗时 12 秒，其中 10 秒来自外部 API 调用，同时工具返回值的解析错误率从 0 变成了 100%。告警当天就能触发，而不是四天后靠用户投诉倒逼排查。

4.3 第三类：让系统架构可被评估

4.3.1 建立清晰的工具策略

工具是智能体接触真实世界的手——它通过工具查数据、调 API、执行业务逻辑。工具的质量直接决定了智能体的行为质量，但很多团队在这里犯的错误不是工具写得不够多，而是工具描述得不够清晰。

工具定义的质量，比工具本身的数量更重要。

看一个对比。同一个函数，两种写法：

模糊写法：”获取收入数据“
精确写法：”获取指定区域和时间段的季度营收数据，返回值单位为百万美元。需要区域代码（EMEA、APAC 或 AMER）和季度（格式 YYYY-QN，例如 2024-Q3）。“

区别不只是文字多少。模糊的描述让智能体必须”猜”：什么是有效输入？返回值是什么单位？这个工具和另一个相似的工具区别在哪里？猜对了还好，猜错了，智能体会选错工具，传错参数，给出错误答案。

一个完整的工具定义应该包含五个要素：

要素	作用	示例
清晰的名称	直接传达工具用途	`getQuarterlyRevenue` 而不是 `getData`
明确的参数	消除输入歧义	`region`: string（EMEA\|APAC\|AMER），`quarter`: string（YYYY-QN）
返回格式	明确输出结构与单位	`{revenue: number, currency: "USD", period: string}`
错误条件	记录各类失败场景	季度不存在返回 `404`，服务不可用返回 `503`
使用指引	说明何时用、何时不用	当用户询问营收、销售或财务表现时使用；不适用于预测或趋势分析

当工具数量增长到二三十个时，工具目录的管理就变得关键。不同团队不应该重复造同一个数据库连接器，建议维护一个经过安全审查、在生产中验证过的工具目录，新团队从目录里取，而不是从零开始写。同时推荐采用 MCP（Model Context Protocol）作为工具暴露的标准协议——Slack、GitHub、Salesforce 等很多服务已经提供了现成的 MCP Server，可以直接接入，不用再自己封装。

工具还需要具备健壮的错误处理。工具不可用时，智能体不应该崩溃或者用不完整的数据给出错误答案——它应该捕获错误，明确告知用户服务暂时不可用。典型处理策略：瞬时故障自动重试，可能时回退到缓存数据，服务完全不可用时主动告知用户。错误处理做到位，评估也更准确——我们能区分”智能体做出了错误决策”和”工具本身出了故障”，这两种情况的修复方向完全不同。

每个工具都要附代码示例。开发者不应该靠猜来理解工具的调用方式或输出格式——一份完整的示例能节省反复试错的时间，也能大幅降低工具被误用的概率。

清晰的工具定义还有一个实用价值：出了问题更容易定位。如果智能体选错了工具，我们能一眼看出是模型的问题，还是工具描述本身就有歧义。这两种情况的修复方向完全不同——混在一起，调试就会陷入泥潭。

4.3.2 用确定性代码替代模型内部推理

智能体不应该做所有事情。这听起来反直觉，但它是企业级智能体架构里最重要的判断之一。

LLM 擅长的是推理和语言理解：理解用户意图、判断该调用哪个工具、把数据结果解释成自然语言——这些任务需要对模糊输入进行推断，用传统代码实现要枚举成千上万种情况。

传统代码擅长的是确定性操作：计算收入增长率、验证日期格式、执行业务规则条件判断。这些操作有唯一正确答案，用 Python 写一个函数，毫秒级执行，零额外成本，每次结果完全一致。把这类操作交给 LLM 推理，是在用最贵的工具做最简单的活。

正确的架构是：智能体负责编排，代码负责计算。用户问”我们 EMEA 这季度增长了多少”，智能体用推理能力理解意图、决定调哪些数据，然后调用一个确定性函数执行计算，最后再用推理能力把结果解释成自然语言。LLM 只在需要它的地方介入。

亚马逊云科技的实测数据直接说明了这种设计的价值。以”生成下个月的支出报告”为例，对比两种实现方式：

	get_current_date() 作为智能体工具	用代码获取日期，作为参数传入
智能体行为	制定计划 → 调用 `get_current_date()` → 计算下个月 → 调用 `create_report()`	代码获取今天日期 → 传入智能体 → 推断下个月 → 调用 `create_report()`
延迟	12 秒	9 秒
LLM 调用次数	4 次	3 次
总 Token 用量	约 8,500	约 6,200

“获取当前日期”这件事，一行代码就能解决，用不着 LLM。但如果把它设计成一个智能体工具，每次查询就多出 1 次 LLM 调用、约 2,300 个 Token 和 3 秒延迟。乘以每天数千次查询，成本和延迟的差距非常可观。

这背后还有一个工程价值：确定性操作的结果是二元对错，可以用程序直接验证，不需要 LLM-as-a-Judge。把越多操作推向这个方向，系统就越容易测试，评估结果的可信度也越高。

判断原则很简单：如果确定性代码能可靠解决问题，就用代码。如果需要推理或自然语言理解，就用智能体。最常见的错误是默认一切都应该是 Agentic 的——正确答案是智能体和代码协同工作。

4.3.3 多智能体系统保持解耦

单个智能体试图处理太多职责时，问题会系统性地出现：Prompt 越写越长，工具选择逻辑越来越混乱，性能下降，出了问题不知道从哪查起。解决方案是分解——把一个大智能体拆成多个职责单一的专门智能体，让它们协作完成任务。

这和组织人员的道理一样。我们不会雇一个人同时负责销售、工程、客支和财务。我们雇专才，然后让他们协作。智能体系统同理：与其让一个智能体处理三十种任务，不如拆成三个智能体，每个负责十件相关的事。每个智能体有更清晰的指令、更简洁的工具集、更聚焦的业务逻辑。

三种常见的协作模式各有适用场景

顺序模式：任务有天然的先后顺序。第一个智能体取数据，第二个分析，第三个生成报告
层级模式：需要智能路由。一个 Supervisor智能体判断用户意图，分发给对应的专门智能体
对等协作模式：智能体之间需要动态协同，没有中央协调者

多智能体系统最容易出问题的地方是交接点。一个智能体把任务移交给下一个时，上下文必须完整传递——如果用户已经在第一个智能体提供了账号信息，第二个智能体不应该再问一遍。要仔细监控每次交接：哪个智能体处理了哪部分请求？延迟发生在哪个环节？上下文在哪里丢失了？

这里还有一个常见的概念混淆值得澄清：协议和模式是两回事，混用会导致基础设施和业务逻辑耦合在一起。

	协议（智能体如何通信）	模式（智能体如何协作）
层次	通信与基础设施	架构与组织方式
关注点	消息格式、API、标准规范	工作流、角色分工、协调机制
示例	A2A、MCP、HTTP	顺序、层级、对等

同一个协议可以支持不同的模式，同一个模式可以用不同的协议实现。分清这两个关注点，架构决策和基础设施选型才能互不干扰。

解耦还有一个直接的工程收益：每个智能体职责清晰，就可以被独立评估。耦合系统出问题时，无法判断是哪个环节失败了；拆开之后，每个智能体有自己的基准数据集和指标，改进目标清晰，也不会出现”改好了 A，不知道有没有影响 B”的情况。

4.3.4 安全与个性化

从单用户原型扩展到服务数千用户的生产系统时，需要同时解决两件事：安全边界和个性化体验。前者确保用户只能访问自己有权限的数据；后者让智能体记住每个用户的偏好和历史，持续提供更贴合需求的响应。两者共用同一套基础设施——用户身份和权限的隔离，既是安全的保障，也是个性化的基础。

智能体系统的安全有一个最常见的错误设计：在 System Prompt 里写”不要访问用户无权限的数据”，然后依赖 LLM 推理来执行这条规则。

这不可靠。LLM 的推理在大多数情况下表现良好，但它是概率性的，没有任何模型能保证每次都正确执行安全规则。更根本的问题是：LLM 内部的决策过程不可观测、不可审计，也无法被系统性测试。一旦出现安全问题，甚至无法复现它是怎么发生的。

正确的做法是把安全控制外部化：放在独立的 Gateway 和 Policy 层，在工具被调用之前就完成鉴权，LLM 根本没有机会”决定”要不要遵守规则。

这套架构通常分三层：

认证层：用户通过现有的 Identity Provider（Cognito、Entra ID、Okta 等）完成身份验证，拿到携带权限信息的 token。这个 token 在整个会话中全程传递。

授权层（Gateway）：每次工具调用之前，Gateway 拦截请求，验证当前用户是否有权限以当前参数调用这个工具。这里还可以注入第三方服务的 OAuth 凭证、执行自定义的限流或审计逻辑。只有通过检查的请求才能到达实际的工具和数据库。

会话隔离：多用户并发时，每个用户的会话必须完全独立，用户 A 的上下文不能泄露给用户 B。个性化记忆（用户偏好、历史交互）也要按用户命名空间隔离存储。

用户记忆与个性化：会话隔离解决的是安全问题，用户记忆解决的是体验问题——同一套命名空间机制，同时服务于两个目标。智能体可以在用户命名空间下存储偏好（偏好的报告格式、常用的筛选条件）和历史交互（本周已查询过哪些数据），让回访用户得到更连贯、更个性化的响应，而不是每次从零开始。个性化记忆的存储和检索，同样应该经过授权层的管控——用户只能访问自己的记忆，不能跨用户读取。

举个例子：一名初级分析师试图查询高管薪酬数据。如果安全规则写在 System Prompt 里靠 LLM 执行，智能体多数情况下会拒绝——但精心构造的 Prompt 注入可以绕过这种限制，而且无从预测它什么时候会失效。如果把访问控制放在 Gateway 层，这个请求在到达数据库之前就被策略拦截，结果是确定的，与模型当次的推理无关。