肖加森：AI的可复现性挑战（The AI Reproducibility Challenge）

原创文章《The AI Reproducibility Challenge，AI的可复现性挑战》，作者介绍：肖加森，上海千语创想科技有限公司创始人兼首席执行官，正高级工程师、人工智能领域技术专家、天使投资人。深耕人工智能、NLP自然语言处理、云计算与大数据领域十余年，兼具深厚技术研发积累与企业 AI 项目落地实战经验，是国内数字化科创领域代表性技术实践者。兼任多省市科技智库专家，先后担任上海市科技型企业创新资金评审专家、上海市工程系列计算机与信息技术应用专业高级职称评审专家、上海市科技计划软科学重点项目AI评审专家、上海市科学技术委员会科技专家、浙江省科技专家、江西省科技专家、黑龙江省科技专家、黑龙江省自然科学基金评审专家，深度参与各地科创项目评审与行业标准建设，推动数字科技产业规范化、高质量发展。联合高校资深教授共同编著《具身智能数据库技术与应用》、《Java项目实战教程》等高校教材，并担任主编。曾获得CFS第十五届财经峰会2026“科技创新先锋人物奖”“人工智能先锋奖”，2026年9月作为科技领袖受邀出席《财富》世界500强论坛。

肖加森,上海千语创想科技CEO,AI人工智能领域科技专家

当AI成为基础设施，可复现性就不再只是学术问题

2026年的AI已经不再是实验室里的“模型展示”，也不再只是企业系统中的可选插件。它正在深度嵌入软件工程、产品交付、组织协作和商业决策之中。AI Native不是给现有系统加一个聊天窗口，而是让AI能力成为系统运行的默认假设；Deep Embedding也不是简单调用大模型API，而是让AI参与需求理解、代码生成、测试验证、运维监控、用户交互和商业闭环。

但越往深处嵌入，越会暴露一个长期被低估的问题：AI的可复现性挑战。

传统软件工程追求确定性：同样的输入、同样的代码、同样的环境，应该得到同样的结果。可复现性曾经是测试、审计、合规和工程协作的基础。而在AI原生系统中，模型输出具有概率性，数据分布会漂移，提示词会改变行为，工具调用会产生连锁反应，Agent工作流会引入新的不确定性。于是，一个关键命题出现了：如果AI系统无法被可靠地复现，我们如何相信它？如何测试它？如何交付它？如何让它进入生产环境、组织流程和产业系统？

这正是AI架构师必须面对的问题。

一、软件生产力嵌入：AI Coding不是“更快写代码”，而是“更复杂地管理不确定性”

AI Coding正在重构从编码到交付的工程链路。开发者不再只是编写确定逻辑，而是在与模型共同生成代码、测试、文档和部署脚本。表面上，生产力提升了；深层看，工程对象变了。

传统代码的可复现性主要依赖版本控制、构建脚本、测试用例和环境配置。AI生成代码则引入了新的变量：

·同一提示词可能产生不同实现；

·模型版本更新会改变输出风格甚至正确性；

·上下文长度、温度参数、工具返回结果都会影响生成；

·开发者可能接受了一段“能跑但不可解释”的代码；

·测试通过并不代表逻辑稳定，因为下一次生成可能不同。

因此，AI原生研发体系不能只问“代码是否通过测试”，还必须问：这段代码是如何产生的？它依赖哪些模型、数据、提示词、工具和环境？如果环境变化，它是否仍然成立？

可复现的AI软件工程，至少需要四类资产同时被管理：代码、数据、模型与提示词。缺少任何一类，复现都会断裂。

二、系统嵌入：Agent Loop让不确定性从“输出层”进入“控制层”

如果说AI Coding主要影响开发效率，那么Agent Loop则把AI的不确定性推到了系统核心。

传统系统的工作流是显式的：规则、状态机、API调用、事件总线、批处理任务，都是工程师预先定义的。Agent系统则不同，它会根据目标拆解任务、选择工具、调用服务、评估结果，再决定下一步。它不再只是返回一段文本，而是在系统中执行动作。

这带来一个结构性变化：AI从“回答者”变成了“决策者”。

当Agent成为软硬件系统的默认组件，可复现性挑战会从模型输出扩展到整个执行链路：

·工具返回的数据变化，会导致Agent路径不同；

·外部API延迟、限流或错误，会改变重试策略；

·记忆机制会累积历史偏差；

·多Agent协作可能出现不可预期的交互；

·同一目标在不同时间可能产生不同执行计划。

更复杂的是，很多Agent行为并不是完全错误的，而是“合理但不可复现”。这在实验环境中可能被接受，但在金融、医疗、制造、教育、政务、工业软件等场景中，却会直接影响可靠性、责任边界和系统信任。

所以，Agent系统不能只追求“更聪明”，还必须建立可观测、可回放、可审计、可回滚的工程机制。一个成熟的Agent架构，应当能够回答：它为什么选择这个工具？它看到了哪些上下文？它执行了哪些动作？如果再次运行，哪些部分会稳定，哪些部分必然变化？

三、组织嵌入：AI Native重塑团队，也重塑责任边界

AI Native对组织的影响，不只是增加一个“AI团队”，而是改变技术团队、企业架构和产业协作方式。

过去，工程师负责实现需求，测试负责验证行为，运维负责保障稳定，产品负责定义价值。AI原生系统中，这些边界会被重新划分。产品经理可能需要设计提示策略；测试工程师需要评估概率性输出；运维团队需要监控模型漂移；安全团队需要审查工具调用；法务与合规团队需要确认数据使用、输出责任和人机决策边界。

可复现性因此成为组织问题。

如果一个AI系统出现问题，责任不能只落在“模型不稳定”上。企业需要知道：

·使用的是哪个模型版本？

·提示词是否被变更？

·训练或微调数据是否被更新？

·向量库、知识库、工具接口是否发生变化？

·用户输入是否引入了新的分布？

·是否有足够日志支持事后复盘？

·是否存在人工确认环节？

·哪些决策允许AI自主执行，哪些必须人工审批？

没有这些能力，AI系统就难以进入核心业务流程。因为企业真正需要的，不只是AI“能做什么”，而是AI做错了什么时，我们能否定位、修复、验证并防止再次发生。

四、AI可复现性的四个层次

要应对这一挑战，不能停留在“固定随机种子”的层面。AI原生系统的可复现性至少应分为四个层次。

很多团队目前只解决了模型层的一部分，却忽视了数据层和组织层。结果就是：实验环境表现良好，生产环境难以稳定；单次演示成功，长期运行不可控；局部效率提升，系统风险上升。

真正的AI可复现性，不是要求所有输出完全一致，而是要让变化可解释、差异可检测、错误可定位、行为可约束。

五、构建可复现的AI原生系统：架构师的六项能力

面对AI Native和Deep Embedding，AI架构师需要建立新的工程标准。

第一，版本化一切。代码、数据、模型、提示词、工具配置、知识库、向量索引、评估集都应纳入版本管理。模型不能只记录名称，还要记录版本、参数、推理配置和调用上下文。

第二，建立AI实验与生产之间的桥梁。实验环境中的成功不能直接等同于生产可用。架构师需要定义从原型、灰度、受控发布到全量上线的门槛，包括稳定性、准确率、延迟、成本、安全性和人工复核机制。

第三，设计可观测的Agent链路。Agent系统必须记录目标、计划、工具调用、返回结果、决策依据和最终输出。没有这些日志，Agent就只是黑盒；有了这些日志，它才可能成为可审计的系统组件。

第四，把评估从“人工看结果”升级为“持续评估”。AI系统需要持续监控输出质量、分布漂移、工具失败率、用户反馈和异常行为。评估不能只在上线前做一次，而应成为运行时的常态能力。

第五，设置人机协同的安全边界。对于高风险任务，AI不应完全自主决策。架构师需要明确哪些场景可以自动执行，哪些必须人工确认，哪些必须保留回滚路径。

第六，把可复现性纳入组织流程。技术团队、产品团队、安全团队和合规团队需要共同定义AI系统的使用规范。可复现性不仅是工程问题，也是治理问题。

六、从“能用”到“可信”：AI原生系统的下一阶段

AI Native的真正价值，不在于让系统看起来更智能，而在于让智能能力可靠地嵌入真实业务。深度嵌入意味着AI不再处于边缘，而是进入核心链路；这也意味着任何不可复现、不可解释、不可审计的问题，都会被放大。

未来的AI架构竞争，可能不只是模型能力的竞争，更是可复现工程体系的竞争。谁能把模型、数据、提示词、工具、日志、评估、合规和人机协同组织成一个稳定闭环，谁才能让AI从演示走向生产，从效率工具走向基础设施。

可复现性不是限制AI创新的枷锁，而是AI进入复杂系统的通行证。它决定了一个AI系统能否被测试、被交付、被信任、被规模化，也决定了AI原生能否真正从概念走向产业现实。

最后，我希望与更多同行一起思考：当AI成为系统的默认组件，我们如何构建一个既智能、又可信的工程世界？