FDE落地

Q: 开通科技 / FDE 是做什么的？

重庆开通网络科技有限公司（开通科技，品牌 FDE）提供 AI 能力与落地实践服务：智能体开发与运营、电商 AI 应用（AIEC）、企业智能营销 GEO，并配套诊断、咨询、培训与社区内容。

Q: 三大场景应用分别是什么？

FDE智能体（/agents）做企业级智能体开发与运营；AIEC（/aiec）做电商履约采销与上架自动化；GEO（/geo）做生成式引擎优化，提升品牌在 AI 回答中的正确引用。

Q: 如何开始 AI 落地？

可从免费诊断（/offers/diagnose）摸底优先级，再进入 AI 能力（/ai）、AI 落地路径（/delivery）或对应场景应用站点深入了解。

# 评估企业级智能体：从原型验证到生产就绪 **原文链接：https://aws.amazon.com/cn/blogs/china/part-2-enterprise-intelligent-validation/** **来源：AnySearch 企业AI** 智能体的难点不在于"能不能做到"，而在于"能不能每次都做到"。本文是企业生产级智能体开发部署指南系列的第 2 篇，给出一套可落地的智能体评估方法论——评什么、怎么评、如何从零构建。 一、引言 智能体与传统软件有本质不同——非确定性、Prompt 即源代码、依赖会自己动——因此传统 QA 框架在它身上系统性失效，需要一套新的开发生命周期 ADLC。在那个六环节的飞轮里，"定义'好'"排在动手构建之前，而 Evaluation 是后续工程实践的重要基础：没有它，团队不知道自己在哪里，也不知道改了之后有没有变好。 几乎每个构建过智能体的团队都遇到过同一个场景：demo 时一气呵成，一旦开始接入真实流量，它却开始"间歇失效"——同一类请求，十次里有一两次走错工具，或把一个本该拒绝的操作执行了。对于智能体来说，能力（capability）与一致性（reliability/consistency）并不是一回事。能力回答"它能不能做到"，一致性回答"它每次都能做到吗"；前者靠一两个亮眼样例就能展示，后者只能靠成规模、反复的评估去逼近。 智能体把多步推理、工具调用、外部状态写入耦合在一起，任何一环的随机性都会被链式放大——这正是"Demo 和生产之间的鸿沟"在评估视角下的样子：一边是 Gartner 预测 2028 年约 33% 的企业软件将内置 agentic AI 的汹涌需求，一边是 MIT 调研中仅约 5% 的组织报告生成式 AI 项目取得高回报的稀薄成功率。把两者连起来的，恰恰是能不能可信地判断"这个智能体是否真的交付了"。评估，就是把"the agent ran（它跑了）"翻译成"the agent delivered, here is the evidence（它交付了，这是证据）"的那道工序。 二、三个常见的智能体评估误区 误区一：仅关注智能体准确率指标。把多步智能体压成一个"对/错"或一颗"质量星级"，会同时掩盖两类信息：质量很高但延迟/成本很差的情况，以及"答案对了但过程全错"的侥幸。对多步系统而言，最终输出的单一准确率远远不够。 误区二：严格比对工具调用序列。直觉上"轨迹对了才算对"，于是有人用预期工具调用序列做精确匹配。但这种做法极其脆弱：智能体换一个等价路径、调换两个无依赖步骤的顺序，就会被判失败。它测的是"像不像我写的脚本"，而不是"有没有把事办成"。 误区三：先评估、后观测。很多团队急着搭评分流程，却没有先把生产里的执行轨迹（trace）沉淀下来。结果是：分数掉了，却不知道掉在哪一步、为什么掉。正确的顺序是先有可观测性，再谈打分，没有 trace 的评估是盲测。 三、评估方法论框架：两根支柱 在与企业客户合作的实践中，我们沉淀出一套两支柱 + 三类打分器的评估方法论，分别回答"用多粗的镜头看"与"一个分数有多大分量"两个问题。 支柱一（三种评估粒度）决定评估的粒度有多深——从只看最终响应（黑盒），到看完整执行轨迹（玻璃盒），再到看单步细节（白盒）。支柱二（三层证据权重）决定每个分数有多大分量——从机械可验证（Layer 1）、到半客观（Layer 2）、再到默认拒评（Layer 3）。两根支柱互相正交：同一个粒度上的指标可以来自不同证据层级，反之亦然——它们不是一一对应的两套层，而更像一个 3 × 3 的矩阵。三类打分器（代码规则、LLM-as-a-Judge、人工）是把这个矩阵填满的工具，它们与三层证据权重天然对齐。 3.1 支柱一：三种评估粒度（黑盒、玻璃盒、白盒） 黑盒（Black-Box）——最终响应。只需输入、输出、上下文即可判定：相关性、完整性、简洁性、语气、事实正确性、输出结构是否合规。它适合端到端验收，也最贴近用户感知。 玻璃盒（Glass-Box）——完整轨迹。看整段消息序列与工具调用，精确定位推理在哪一步出错：目标是否达成、工具选择与参数是否正确、轨迹是否高效、是否产生幻觉。 白盒（White-Box）——单步。评单个步骤或单次工具调用的正确性，是定位与归因的最细一层。 三个粒度互补：黑盒告诉你"结果好不好"，玻璃盒与白盒告诉你"为什么、在哪儿"。这里有一条经验：优先按结果（outcome）打分，而非死磕路径；对多组件任务设计部分得分（partial credit）；轨迹分析用来归因，而不是用来做工具序列的精确匹配。 3.2 支柱二：三层证据权重框架 第二根支柱常被忽视，却最为关键。它的出发点是一个朴素的事实：并非所有质量都同样可测，而一个分数会带来后果（决定是否上线、是否付款、是否放行），因此每个分数携带的"证据权重（evidentiary weight）"必须被显式标明。据此，我们把所有指标按"能被多严谨地验证"分到三层，每个指标只归一层： 第 1 层——机械可验证（Mechanically verifiable）。纯代码、零歧义判定：schema、格式、延迟、成本。结果确定，任何一方都能复算——这是最强的证据，在审计与争议场景下可被辩护。 第 2 层——半客观（Semi-objective）。由模型在受控条件下稳定打分：相关性、正确性、忠实度、一致性。它非确定、不可逐位复算；只有在固定评判器（pinned evaluator：锁定模型、prompt、temperature、seed）下，其分数才作数。 第 3 层——主观（Subjective）。没有任何评判器能稳定打分的维度（例如"这个够不够有创意？"）。默认拒评（refused by default）——在 rubric 协商阶段就把它标出来，而不是强行给一个假装客观的分。 这层框架给出一个清晰的心智模型：一个分数，只能在它所在层支持的严谨度上被当作证据使用。由此也能推出一组该刻进团队习惯的反模式：不要把质量压成单一星级合成分；不要给用户展示裸小数（那是假精度，宜用字母档加命名置信度）；不要跨任务类型套用统一阈值（0.75 在创意题和严格 schema 上意义完全不同）；不要把延迟、成本藏起来，它们是一等的业务指标。 3.3 打分器的选择 支撑这两根支柱的，是三类打分器（grader）的组合使用： - 代码规则（Code-based）：快、便宜、客观、可复现；但脆，只覆盖可程序化判定的部分。 - 模型 / LLM-as-a-Judge：灵活、可扩展、能捕捉细微语义；但非确定，需对照人工校准。 - 人工（Human）：金标准；但昂贵、慢、难规模化。 它们与三层框架天然对齐：第 1 层用代码规则，第 2 层用经校准的 LLM-as-a-Judge，人工则负责抽样校准与最终仲裁。 在企业落地时，这三类打分器有明确的优先级与分工： 程序化、可验证的检查优先执行。低成本、客观、可信——凡是能写成代码断言的（schema、格式、敏感词、延迟、成本、关键参数），绝不交给 judge 模型。这既是省钱，更是把最强证据放在最前面。 LLM-as-a-Judge 只管主观维度，且评分标准（rubric）必须由 SME 校准。judge 模型人人可买，但"什么算好"的 rubric 要由懂业务的领域专家写出来、再对照人工标注验证一致率——否则你得到的是一个自信但不对齐业务的打分器。 SME/人工审核是企业的核心优势，要用在刀刃上：标注黄金集，以及每次发布前的抽检。外部模型与评估平台是人人可得的通用件，唯独"懂你业务的人的判断"买不到——这正是企业评估体系里最稀缺、也最该被制度化沉淀的资源。 把两支柱与打分器合起来看，就是一张矩阵：行是三种粒度、列是三层证据权重，每个格子放一个示例指标、由对应的打分器填充。它直观地说明了两支柱如何交叉、空格（如"白盒 × 主观"）为何通常不评估，以及人工评估如何横跨各层。 3.4 企业到底要测什么：八类测量维度 矩阵搭好了，往里填什么？这里先校准一个定位：企业评估是风险管理加质量保障（QA），而不是研究。它的目标不是刷 benchmark 或发论文，而是控制上线风险、守住质量底线；"好"由领域专家定义，而不是由排行榜定义。 围绕这个定位，企业级智能体评估通常覆盖八类测量维度，分别落到前述的粒度与证据层上：任务完成度与结果正确性、工具调用与参数正确性、推理与轨迹质量、忠实度与幻觉控制、安全与合规（越权、敏感操作、数据泄露）、一致性与稳定性、性能与成本（延迟、Token、单次任务花费）、以及用户体验与语气适配。每一类维度都要明确它属于黑盒、玻璃盒还是白盒，属于第 1、2 还是第 3 层证据，避免出现"用最弱的证据做最重的决策"。 四、评估的工程化落地：从流程嵌入到数据集积累 方法论要产生价值，必须嵌入研发流程。这里的关键区分是能力评估与回归评估：能力评估回答"这个新能力能不能用"，回归评估回答"改了之后原来能用的有没有坏"。前者用于探索期，后者用于每次发布前的守门。 生产漂移的监控同样不可省略。真实流量的分布会变化，模型与依赖也会自己动，因此需要一个持续监控机制：一旦线上指标偏离基线，就要能定位到是数据漂移、依赖变更还是 Prompt 改动引起的。 评估数据集与黄金集的构建，是这套体系最需要长期投入的部分。建议从约 20 个用例的最小规模起步，覆盖主要任务类型与高风险路径，然后随着线上问题不断回填——每一个真实故障，都应该变成一个永久用例。这样评估集才会随业务成长，而不是停留在最初那几十条拍脑袋的样例上。 五、LLM-as-a-Judge 的价值与边界 LLM-as-a-Judge 是第 2 层证据的主力工具，但它有明确的边界。它的价值在于能以低成本、可扩展的方式捕捉细微语义差异，让主观维度的评估第一次变得可批量执行。 但它的偏见必须被正视与缓解：位置偏见（偏好前一个选项）、长度偏见（偏好更长回答）、自我偏好（偏好与自己风格相近的输出）、以及评分漂移。缓解手段包括：随机化选项顺序、控制输出长度、使用与生成模型不同的评判模型、固定评判器配置（pinned evaluator）、并定期用人工标注校准一致率。 在多步智能体场景下，LLM-as-a-Judge 还有根本局限：它擅长评判一段文本好不好，却不擅长判断一长串工具调用与状态变更是否真的把事办成了。因此它应当与代码规则、人工审核组合使用，而不是单独承担上线决策。 六、Agent-based Evaluation：将专家级评审规模化 既然多步轨迹难以用单点评判覆盖，一个自然的思路是：用智能体来评智能体（Agent-based Evaluation）。让评估智能体按 rubric 去读取完整轨迹、检查每一步的目标达成与工具使用、并给出带证据的判定，从而把原本需要专家逐条人工审阅的工作规模化。 它的前提仍然是 rubric 由 SME 校准、以及可观测性先行——没有 trace，评估智能体也无从下手。它的产出应当被当作第 2 层证据，并持续与人工抽检对照校准。 七、最佳实践清单 1. 先埋可观测性，再谈打分；没有 trace 的评估是盲测。 2. 优先按结果打分，路径用于归因，而非精确匹配工具序列。 3. 明确每个分数的证据层级，只在它支持的严谨度上使用。 4. 程序化可验证的检查优先，把最强证据放在最前面。 5. rubric 必须由 SME 校准，并对照人工标注验证一致率。 6. 从约 20 个用例起步构建评估集，每个线上故障都回填为永久用例。 7. 区分能力评估与回归评估，发布前必须跑回归。 8. 监控生产漂移，指标偏离基线要能定位到原因。 9. 不要展示裸小数，用字母档加命名置信度。 10. 人工审核用在刀刃上：黄金集标注与发布前抽检。 八、结论 智能体评估的本质，是把"它跑了"翻译成"它交付了，这是证据"。这要求团队放弃用单一准确率或星级概括多步系统的幻想，转而建立一套由三种评估粒度与三层证据权重…