将智能体AI投入生产的5条经验教训
内容提要
文章指出，AI智能体试点容易、投产难，瓶颈不在模型而在系统工程。企业需构建围绕模型的治理框架，包括确定性规则、仿真测试、可信知识与人工审核；从第一天起设计治理与可追溯性；先定架构再选模型，使模型可替换；尽早引入财务和运营，以业务指标分阶段投资；首个智能体应聚焦窄场景，同时沉淀可复用能力。
延伸解读
治理不是事后检查，而是设计起点
文章强调治理应融入架构设计，而非上线前的审查。对于受监管或敏感数据场景，治理要求甚至决定首个用例的选择。例如有工程公司为满足CMMC Level 2和审计准备，将国防敏感工作排除在第一阶段。实践模式是监督式自动化：智能体执行，人工审批重大后果动作，并保留操作痕迹。这样当审计方或客户追问时，团队能回答智能体做了什么、为什么做。
模型可替换性比选型更重要
文章指出最佳模型可能半年后就变了，若系统绑定单一供应商，其他模型的进步会变成昂贵迁移。更好的做法是把模型当作架构中可替换的部件，先定义上下文如何进入系统、工具如何调用、权限在哪、输出如何评估、动作如何追踪，再选择最适合任务的模型。这种灵活性还关乎隐私、成本和部署要求，随着本地硬件上可行模型增多，自托管与托管选项之间的选择也更多。
业务指标驱动分阶段投资
文章发现引人注目的智能体用例往往来自财务和运营，而非工程团队。有公司用智能体审核费用收据是否符合联邦采购规则和HR政策，估计节省70%时间；工业服务公司探索加速SAP工作；医疗科技公司将AI应用于非技术团队。共同点是运营杠杆：减少重复工作、提升吞吐量、在不增加等量成本下创造更多产能。领导者采用分阶段投资：小规模探索、较大原型，路径清晰后才实质性投入。
首个智能体要为第二个铺路
文章建议首个生产智能体不必转型公司，而应解决一个真实问题，并让第二个更容易构建。这意味着从输入、决策和结果可理解的窄工作流开始，但构建可复用的底层组件：治理框架、权限、追踪、评估、知识架构和部署模式。成功的第一智能体应留下更好的构建方式，而不仅是可运行软件。动手前可写下第二个智能体应从第一个继承什么，若答案是什么都没有，就应重新考虑架构。
Q&A
为什么AI智能体试点容易但投产难？
因为投产的瓶颈不在模型本身，而在于围绕模型的系统工程。模型只是智能体的一部分，要让智能体可靠，需要构建包含确定性规则、仿真测试、可信知识源、人工验证事实和明确边界的“治理框架”（harness）。没有这个框架，演示很惊艳，但遇到杂乱数据、边缘案例或真实后果的决策时就会崩溃。
如何为AI智能体设计治理机制？
治理应从第一天就设计，而不是上线前的审查。具体做法包括：采用监督式自动化，让智能体执行工作，但要求人工批准有重大后果的操作，并保留操作痕迹；从试点阶段就将追踪和人工审批内置到系统中。对于受监管或敏感数据，治理还能决定优先实施哪个用例。
为什么应该先定架构再选模型？
因为今天最好的模型六个月后可能就不是了。如果系统假设只用一个供应商，其他地方的重大改进都会变成昂贵的迁移。更好的方法是将模型作为架构中可替换的部件：先定义上下文如何进入系统、工具如何调用、权限放在哪里、输出如何评估、操作如何追踪，然后再选择最适合任务的模型。这样能灵活应对性能、隐私、成本和部署要求的变化。
财务和运营团队为什么要尽早参与AI智能体项目？
因为一些最有吸引力的智能体用例并非来自工程部门，而是来自财务和运营。例如，有公司用智能体审核费用收据，节省约70%时间；有工业服务公司用AI加速SAP工作；有医疗科技公司在非技术团队应用AI。共同点是运营杠杆：减少重复工作、提高吞吐量、在不增加同等成本的情况下创造更多能力。尽早参与还能帮助以业务指标分阶段投资，避免只推销智能体而推销商业案例。
第一个生产级AI智能体应该怎么规划？
第一个智能体不需要转型整个公司，而应解决一个真实问题，并让第二个智能体更容易构建。具体做法：从输入、决策和结果都可理解的窄工作流开始；但构建可复用的底层组件，包括治理框架、权限、追踪、评估、知识架构和部署模式。在开始前，写下第二个智能体应该从第一个继承什么；如果答案是什么都没有，就重新考虑架构。
将AI智能体投入生产的关键经验有哪些？
文章总结了五条经验：1）构建治理框架而不仅是智能体；2）从第一天起设计治理；3）先选架构再选模型；4）尽早引入财务和运营；5）从窄场景开始但为未来构建可复用能力。核心观点是：投产不是模型问题，而是系统问题，需要围绕模型构建治理框架、将治理视为架构的一部分、保持技术选择灵活、连接业务成果并创建可复用能力。
