2026年9月18日，Hoodline报道了一则趣闻：美联航的客服聊天机器人向客户Alison Gil表示，她价值200美元的旅行积分自存入之日起五年内有效。然而，联合航空随后告知她，这些积分实际上将在2026年9月27日到期。最终，美联航承认了聊天机器人的错误，并向Gil补发了一张替代旅行证书。
看起来，AI智能体刚进入企业环境，风险就已初露端倪：AI给出错误答案，却自信满满地说“没问题”“相信我”，即便在相对成熟的客服机器人领域，问题依然存在。
这种失控现象有多普遍？根据Gartner 2025年6月的官方新闻稿预测，到2027年底前，超过40%的Agentic AI项目将被取消，原因之一正是风险控制不足。
Scale AI在论文《READY》中更为直白地指出：“一个AI智能体可能在基准测试中表现优异，却仍然不适合实际部署。”
许多企业在采购时，习惯优先评估模型选择，因为直觉告诉我们，能力的瓶颈在于模型。但行业实践却揭示了不同的现实——
对于AI企业级部署而言，模型仅代表能力，外围系统才是生产力的关键。
2026年，围绕“模型之外还需要什么”这一问题，行业陆续提出了几个新概念，包括：
驭具工程（Harness Engineering）。
2026年初，HashiCorp联合创始人Mitchell Hashimoto在一篇博文中命名了这一概念，随后Anthropic、Thoughtworks、LangChain等机构扩展传播。其核心主张是：智能体 = 模型 + 驭具。模型外部的运行外壳——循环控制、工具调度、记忆、护栏、沙箱——才是将能力转化为可用性的关键。据BCG 9月15日发布的报告，驭具工程“围绕AI智能体构建了一个类似个人电脑操作系统的五部分结构，从而建立有效的治理、问责与适当控制”。
图编排工程（Graph Engineering）。
年中，当单个智能体的循环不再够用时，行业开始探讨将多个智能体编排成图——节点是智能体，边是数据流与控制流。根据8月26日发布在arXiv的论文《Graph Engineering in the Era of LLM Agents》，图编排工程“在单个智能体的基础上，通过任务组织、智能体协调和运行时状态管理，赋能系统级智能”。
驭具解决了“一个智能体如何稳定运行”的问题，图解决了“多个智能体如何协作”的问题。
但两者回答的都是“如何构建”。还有一个更根本的问题悬而未决：你怎么知道构建对了？上线之后，如何确保仍然正确？
SymphonyAI的CEO Sanjay Dhawan的判断直截了当：“一个通用智能体在受控条件下可能看起来令人印象深刻。但一旦进入企业运营，面对那些对一线工作者来说显而易见、对模型来说却完全不可见的约束、依赖关系和判断力要求，它就开始力不从心了。”
OpenAI成立了专门的部署公司，微软投入巨额资金和人力建立Microsoft Frontier Company，而亚马逊云科技则投入10亿美元建设前置部署工程（FDE）。三大巨头同时将重金押注于“部署”，这本身就说明问题——模型构建完成后到上线之间，存在一条巨大的鸿沟。
这一切都恰逢其时。
在刚刚结束的GTLC全球技术领导力峰会·上海站上，亚马逊云科技架构师经理吴迦德进行了一场主题演讲，内容围绕白皮书《企业生产级智能体开发部署指南》的解读与实践展开。该白皮书由亚马逊云科技在2026年6月发布，其中提出了智能体开发生命周期（Agent DLC）概念——从公开的互联网信息来看，这是业内第一套以“评估”为核心、完整覆盖智能体从定义到持续改进全生命周期的系统性方法论。
智能体开发生命周期的核心机制可以概括为：放行由评估决定。达标即放行，未达标则返工。不由人在会议上拍板决定。
这很像传统软件的持续集成/持续交付流水线：代码提交后自动运行测试，测试通过才能合并到主干并发布。智能体开发生命周期做的事情类似，但对象从代码换成了智能体的行为。
智能体开发生命周期包含六个环节——定义、构建、评估、发布、观测、回流——形成一个持续转动的闭环。其中“发布”是一道门。门前，团队在“定义-构建-评估”三个环节之间高频往复，一次上线前可能迭代几十甚至上百轮。
门后，“观测”和“回流”持续运行：生产中遇到的新边界情况、新的失败模式，被自动采集回来，补充到黄金标准中，使下一轮评估更贴近真实世界。
所谓的黄金标准是什么？
黄金标准由两部分组成。第一部分是评估规范——定义“什么算对”，即五个维度的判据和三档门槛；第二部分是黄金轨迹集——这是一套确定的、可复现的数据集，有基线准确性，用于回归测试，由生产链路追踪，持续回流补充。
两者共同构成了企业在智能体落地过程中积累的差异化资产。我们重点展开聊聊评估规范的内容。
评估规范可以粗略理解为一个判据表——它将团队对智能体的每一项要求，从“能理解客户意图”到“不能编造信息”到“单次调用成本不超过X元”，全部转化为可自动测量的判据。
平台可以换，模型可以换，但这份编码了所有真实失效方式和业务判断的标准，是企业从零构建并可以持续复用的。
判据沿五个维度设置：
每条判据还分为三档：
三档必须在首次评估之前冻结，避免“先看分数再定标准”的自我安慰。
有一点值得特别说明：五个维度是“评估”的坐标系，而非“构建”的组件清单。构建期搭建的是检索管线、提示词、工具定义等工程能力；评估期则使用对应维度的评估器去衡量这些能力的效果。一个维度可能涉及多项工程能力，一项工程能力也可能影响多个维度。理解这种“多对多”关系，才不会将评估变成走过场的清单打勾。
评估，可能是智能体开发生命周期六个环节中最值得单独探讨的部分。
原因有三。
第一，评估是整个链条中唯一同时承担“质量判断”和“放行决策”双重角色的环节——它既要给出分数，又要依据分数做出“放行还是打回”的决定，任何偏差都会直接传递到生产环境。
第二，传统软件测试有确定性的对错——函数返回值要么等于预期、要么不等于。但智能体的输出是自然语言和多步行为的组合，同一个问题的正确回答可能有无数种表达方式，“什么算对”本身就需要被定义和校准。
第三，也是最容易被低估的一点：评估本身依赖大型语言模型作为裁判，而裁判模型自己也会犯错。如果你的评估体系有系统性偏差，跑出来的分数越好看，你离真实世界就越远。
如果评估做错了，整个智能体开发生命周期就空转了——我们以为系统在持续改进，其实是在持续自欺。
白皮书中记录了一个真实教训：团队使用正确性（Correctness）评估器跑了13条用例，结果全部零分。深入调查后发现——裁判模型的知识截止时点早于被评内容，相当于拿一把过期的尺子去衡量新东西。将评估方法换成忠实性（Faithfulness，相对于“幻觉”而言）后，同样13条用例，全部通过。
这两个指标有本质区别。正确性问的是“答案对不对”，需要裁判自身具备正确知识。忠实性问的是“回答中的断言是否被上下文支撑”——裁判不需要自己懂，只需要对照材料检查。
白皮书列出了四种偏差及其对策：
关于校准门槛，白皮书也给出了一条硬性规定：裁判模型与人的一致率，要达到人与人之间的一致率水平。 达不到，就不能将裁判作为自动化工具使用。
当然，仅有宽泛框架，白皮书仍难免被质疑为“讲大道理”。亚马逊云科技比较务实的一点在于，在《企业生产级智能体开发部署指南》中提供了具体工具。例如：
智能体做错了，到底是检索的问题还是生成的问题？这是修复前必须回答的第一个问题。白皮书给出了一个按顺序排查的方法——依次问四个问题，第一个答“否”的地方就是根本原因。
先问“该取的内容取到了吗”，对应上下文召回（context recall），检查检索侧。如果取到了，再问“是照着资料回答的吗”，对应忠实性（faithfulness），检查生成侧。如果照着答了，再问“资料本身对吗”，对应正确性（correctness），检查知识库。如果资料也没问题，最后问“回答的是所问的吗”，对应响应相关性（response relevance），回到认知维度检查意图理解。
这里有一个容易踩的坑：忠实性只问“回答中的断言是否被上下文支撑”，不问“上下文中是否有该有的内容”——后者是召回（recall）的事。两个指标必须搭配使用，少了任何一个，排查链条就断了。
评估告诉你“不通过”。然后呢？“不通过”本身不可执行——你需要知道“改哪里”。白皮书将归因拆分为三级，每一级指向完全不同的修复方向。
会话级：智能体前后矛盾、遗忘自己的身份或目标——需要修改目标管理与记忆机制。轨迹级：检索了错误的知识库、工具调用次序不对——需要修改检索管线与工具编排。步骤级：某一步的输入参数类型错误、单步推理逻辑有误——需要修改具体提示词或参数。
没有分层归因，评估的结论就停留在“分数低”三个字上，无法转化为工程行动。
评估有价值，评估也有成本。白皮书坦率地指出：评估器本身是成本大头——每一条追踪记录（trace）经过裁判模型一次，就是一次独立的大型语言模型调用。如果使用模拟测试（simulation），还要加上智能体（actor）的调用费。在进行规模化在线评估之前，必须先算清楚这笔账。
同时，合格标准是通过率，而非二元判定。同一个问题每次措辞不同，智能体的回答可能都对但表达各异。合格线由业务方确定，不同场景的容忍度天差地别——编码助手允许反复尝试，但客服每五次错一次，就意味着每第五位客户遭遇一次真实失败。
修复优先级，白皮书给出了一条明确的路径：先确认分数本身可信，再检查数据质量，再调整提示词，最后才更换模型。多数提升来自提示词、工具描述与检索策略，而非更换模型。
上升到全局来看，评估器、运行时、可观测链路、三级归因、A/B测试、金丝雀发布——智能体开发生命周期的每一环都需要基础设施支撑。如果全部自建，周期以月计，且中小企业难以承受开销。
智能体开发生命周期的每一环都能在AgentCore上找到对应的托管能力。它允许企业将精力集中在判据设计和黄金标准这类差异化资产上，而将评估器、运行时、可观测这类重复劳动外包出去。
我们可以通过一张表看清AgentCore的覆盖面：
AgentCore不绑定框架，CrewAI、LangGraph、LlamaIndex、Google ADK、OpenAI Agents SDK、Strands、自定义框架均可接入。它同样不绑定模型，协议支持MCP与A2A。
作为AgentCore的用户，英国二手车拍卖平台Motorway将错误结果从每8次出现1次降低到每50次出现1次，工具选择准确率从87%提升到98%。服务全球8亿用户的创意平台Fotor（成都恒图科技）将流程耗时从分钟级压缩到秒级，Fotor新一代智能体架构的上线周期缩短到了1天。
巴西医疗集团Rede Mater Dei则将工具选择准确性提升了38个百分点，4个月内实现517%的投资回报。Cox Automotive用不到一年时间将17个智能体投入生产。
更多技术细节和实施案例，你可以下载亚马逊云科技白皮书《企业生产级智能体开发部署指南》仔细阅读全文。
没有任何系统能保证零失误。智能体开发生命周期要做的，是让错误在造成后果之前被发现。
“发布前，以标准考核Agent；发布后，以世界考核标准。”
这句话来自白皮书。也适用于每一个正在将智能体推向生产的团队。
本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：王一鹏，36氪经授权发布。在构建智能体时，可参考九游体育 (中国)官方网站-九游体育 (中国)官方网站的相关实践。