智能化软件开发微访谈·第四十四期：智能体工程发展趋势

CodeWisdom · 2026-09-29 08:00 · 25 阅读

CodeWisdom 2026-09-29 08:00 上海

本次微访谈于9月24日举行，邀请了10位专家分享自己的观点和看法。

CodeWisdom

智能体工程发展趋势

微访谈 · 第四十四期

背景介绍

近两年来，“AI工程”几乎成了AI圈更新最快的造词现场：从2023年的Prompt Engineering，到 2024-2025年的Context Engineering，再到2026年初火起来的Harness Engineering（驾驭工程），一个著名的公式被反复引用—“Agent = Model + Harness”。紧接着，Loop Engineering、Agentic DevOps等新名词又层出不穷，仿佛只要再发明一个“XX 工程”，智能体系统的可靠性问题就能迎刃而解。

然而，热闹的名词迭代之下，一个略显尴尬的现实是：当我们把视线从Demo和黑客松转向企业真实生产环境时，智能体的落地仍然举步维艰。模型单轮任务成功率看似亮眼，但跨系统、跨数据、长程任务的一致性与可靠性远未达标；智能体被当作一个孤立的“模型外壳”来调优，却很少被放回企业既有的软件架构、数据资产与业务流程中去系统设计。事实上，真正严肃的智能体应用从来不是“一个模型加几个工具”，而是模型自主行为、传统代码组件、数据谱系与业务规则深度交织的复杂系统—它对一致性、可观测、可治理、可演进的要求，丝毫不亚于甚至远超传统软件系统。

那么，从提示工程、上下文工程到驾驭工程，这场AI工程方法论的演进究竟走到了哪一步？哪些是真正的范式跃迁，哪些只是换了包装的旧经验？模型、代码、数据、流程在智能体系统中应当如何有机融合？传统软件工程与系统工程几十年沉淀下来的需求工程、架构设计、测试、DevOps 与可靠性保障，在智能体时代该如何继承与重构？面对金融、科研、工业等严肃场景对一致性与可控性的硬约束，当前的技术栈距离真正可信赖的企业级智能体系统还有多远？下一代智能体开发平台与工具链会如何演化，软件工程师的角色又将被如何重塑？围绕这些问题，我们邀请了多位一线技术专家齐聚一堂展开探讨和交流，希望能够帮助大家更好地理解智能体工程的真实面貌与落地路径。

主持人

彭鑫

复旦大学

复旦大学计算与智能创新学院副院长、教授，国家级高层次人才计划入选者。中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，中国汽车工程学会汽车基础软件分会副主任，《Journal of Software: Evolution and Process》联合主编（Co-Editor），《ACM Transactions on Software Engineering and Methodology》、《Empirical Software Engineering》、《Automated Software Engineering》、《软件学报》等期刊编委。2016年获得“NASAC青年软件创新奖”，2023年入选上海市东方英才拔尖项目，2024年获得“中创软件人才奖”。主要研究方向包括软件智能化开发、AI原生与云原生系统、泛在计算软件系统、智能汽车及工业软件等。研究工作多次获得IEEE Transactions on Software Engineering年度最佳论文奖、ICSM最佳论文奖、ACM SIGSOFT杰出论文奖、IEEE TCSE杰出论文奖等奖项。担任2022年与2023年CCF中国软件大会（CCF ChinaSoft）组织委员会主席与程序委员会共同主席，以及ICSE、FSE、ASE、ISSTA、ICSME、SANER等会议程序委员会委员。

访

谈

嘉

宾

白硕

白硕，上海证券交易所原总工程师，恒生研究院前院长，CCF数字金融分会常务执委，智能投研联盟（ITL）首席技术专家。持续深耕金融科技数十年，目前专注智能体行业落地的架构研究和金融垂域的上下文工程。

王昊奋

同济大学长聘教授、博士生导师，聚焦知识图谱与知识增强大模型研究，以及AI产业落地。核心成果包括全球首个知识增强推理模型KAG-Thinker（超万Star）、记忆操作系统MemOS（日调用量超150万次）及大模型评测平台AI-Ceping（30万+月活），已落地机场调控、金融风控等多场景。出版《知识图谱》《检索增强生成：理论与实践》《记忆工程》等6部专著。他曾担任两家AI独角兽企业CTO，构建了全球首个可交互养成的虚拟偶像—“琥珀·虚颜”；所构建的智能客服机器人已累计服务用户超过100亿人次。目前，他担任全球最大开放知识图谱社区OpenKG首任轮值主席，中国计算机学会术语工委副主任，自然语言处理专委会副主任（执行），中国中文信息学会理事，大模型专委会指导委员，语言与知识计算专委会副主任，上海市计算机学会自然语言处理专委会副主任等社会职位。

陈华钧

浙江大学求是特聘教授，主要研究方向为人工智能、知识图谱、自然语言处理、AI for Science等，牵头发起中文开放知识图谱OpenKG，以一作或通讯作者在Nature Machine Intelligence、Nature Biotechnology、Nature Computational Science, Nature Communications、ICLR、ICML、NeurIPS、IJCAI、AAAI、ACL、EMNLP、WWW、SIGIR、KDD、VLDB、Proceeding of IEEE、ACM Computing Survey、National Science Review等国际顶会顶刊上发表多篇论文。担任浙江省数智科技研究会副会长，中国人工智能学会知识工程专委会副主任，中国中文信息学会语言与知识计算专委会副主任。入选浙江省有突出贡献中青年专家，浙江省高层次人才特殊支持计划科技创新领军人才，斯坦福全球前2%顶尖科学家终身榜单（人工智能领域）。作为项目负责人及首席科学家主持科技部创新2030“新一代人工智能”国家科技重大专项“知识增强的科学具身智能体平台及应用”重大项目，并主持负责国家自然科学基金委重大研究计划重点项目、国家自然科学基金联合基金重点项目及多项重大企业合作项目。牵头或作为核心骨干获得省部及国家级科技奖5项，及浙江大学首届优秀教材奖一等奖、中国工信传媒出版集团优秀出版物一等奖等教材专著类奖。

张奇

复旦大学计算与智能创新学院教授、国家级领军人才、浦江国家实验室大模型负责人。兼任腾讯-复旦下一代大模型联合实验室主任，上海市智能信息处理实验室副主任，中国中文信息学会理事、CCF 大模型论坛常务委员、CIPS 大模型专家委员会委员、CIPS 信息检索专委会常务委员。聚焦大语言模型、模型鲁棒性和解释性分析等。在ACL、EMNLP、COLING、全国信息检索大会等重要国际国内会议多次担任程序委员会主席、领域主席、讲习班主席等。著有《自然语言处理导论》和《大规模语言模型：理论与实践》

曹春

南京大学计算机科学与技术系教授，博士生导师。研究方向为计算机软件方法学及智能软件技术。作为负责人主持完成了包括国家高技术研究发展计划（863）课题、国家"核高基"科技重大专项课题、国家重点研发计划课题、广东省重点研发项目课题等多项科研任务，还作为骨干成员参与多项国家级和省部级科研项目。现任南京大学电力产业数智技术研究院院长、南京大学-中创软件联合实验室主任，主持和参与多项面向行业的智能化软件应用落地项目，为国家关键产业的智能化转型升级贡献力量。相关研究成果在IEEE TSE、IST、JSS、《中国科学》等国内外刊物和FSE、ICSE、NeurIPS、ICLR、ASE、ICSME等国际学术会议上发表论文50余篇。曾获教育部提名国家科学技术奖一等奖和国家科学技术进步二等奖。

邸世民

东南大学计算机科学与工程学院教授、博士生导师。入选国家高层次青年人才、香港科学院青年科学家、小米青年学者、紫金青年学者等计划。2022年获香港科技大学博士学位，同年加入香港科技大学，2025年起任教于东南大学，2026年被聘为东南大学青年首席教授。研究领域为智能体系统、数据挖掘与科学智能，主要围绕大模型智能体系统和科学垂域智能体系统展开理论技术攻关和示范应用研发，形成从工具供给、任务规划、工作流与技能演化到角色智能体平台的整体研究路线。

茹炳晟

复旦大学Codewisdom团队首席技术专家，腾讯研究院高级技术顾问，中国计算机学会TF多智能体系统SIG副主席

沈欣

腾讯TVP，智慧零售行业大使，腾讯云架构师联盟理事，腾讯云OPC社区合作导师，北大CIO班、得到AI高研班常驻讲师，中国信通院低代码/无代码推进中心技术专家，长三角数字经济产业高质量发展联盟人工智能专委会主任，广东数字经济专委会副主任，中国饭店协会餐饮数字化专业委员会技术专家，上海交通大学高级金融学院产融中心、上海交通大学终身教育学院特聘讲师

曾任半天妖顾问CIO，喜茶数字化高级副总裁、百果科技首席技术市场官，百果科技首任轮值主席、和君咨询合伙人

周琦

阿里云云原生团队负责人，主要方向：AI 应用架构、Agent构建与治理平台、智能开发与运维、AI 中间件、Agent测评与自进化等。

于璠

中国科学技术大学计算机博士毕业，华为工作17年，现任华为软件领域昇思MindSpore科学家/AI4S首席技术专家，获得中国软件协会卓越工程师/OSCAR开源人物，获聘哈尔滨工业大学客座教授/西安电子科大/山东大学客座教授，科技部2030人工智能重大专项首席科学家，主持华为AI系统核心算法/云计算资源调度/SDN大规模路由等架构和算法的设计和落地，发表专利和论文160余篇。

访谈主题

从Prompt Engineering、Context Engineering、Harness Engineering再到Loop Engineering，“AI工程”领域的这些“新名词”反映了什么样的一种工程化发展路径？这些工程方法和实践在AI技术落地应用中发挥了什么样的作用？此外，这种工程化的发展过程未来还会继续进行下去还是已经到顶了？

当前AI工程特别是以Harness Engineering、Loop Engineering为代表的智能体工程体现了什么样的软件工程和系统工程思考，同时还存在哪些方面的不足？软件工程与系统工程几十年沉淀下来的需求工程、架构设计、测试、DevOps与可靠性保障等方法和实践，在智能体时代应当如何继承与重构？

模型、代码、数据、流程在未来的智能体系统中应当如何有机融合？特别是概率性的神经网络与确定性的符号逻辑如何相互协作，同时是否会产生各种新型的设计模式？

RSI（Recursive Self-Improvement）在智能体工程中发挥着什么样的作用？与软件开发运维一体化（DevOps）之间的关系是什么？实现RSI的关键技术和实践是什么？

面对金融、科研、工业等严肃场景对一致性与可控性的硬约束，当前的工程方法论和技术栈距离真正可信赖的企业级智能体系统还有多远？下一代智能体开发平台与工具链会如何演化，软件工程师的角色又将被如何重塑？

Q&A记录

Question 1

主持人：从Prompt Engineering、Context Engineering、Harness Engineering再到Loop Engineering，“AI工程”领域的这些“新名词”反映了什么样的一种工程化发展路径？这些工程方法和实践在AI技术落地应用中发挥了什么样的作用？此外，这种工程化的发展过程未来还会继续进行下去还是已经到顶了？

白硕：

本人长期深耕B端AI数字化与智能体应用落地领域，持续聚焦企业级AI工程化的体系建设、理念迭代、工具链演进与行业最佳实践沉淀，始终围绕大模型从技术原型走向产业真实落地的核心痛点开展研究与实战探索。

从提示工程、上下文工程到测控框架工程、循环工程的迭代演进，一系列AI工程新名词的更迭，我认为本质上不是概念噱头的翻新，而是行业对大模型落地核心诉求的持续具象化，核心指向长程复杂任务自动化与业务资源、用户语言体系的深度对齐两大核心目标，也是大模型从浅层对话交互向深度实操落地转型的核心动力与核心挑战。根据这一理解，我认为未来这个方向上的迭代，终局是清晰的，不会也没有必要无限进行下去。

另外，AI工程技术体系的迭代升级，并不意味着前置的技术理念与工程方法过时失效，各类技术范式是层层叠加、互补共生的关系，而非新旧替代、优劣淘汰的关系，其中上下文工程的核心诉求更是贯穿AI落地全周期的持续性工程难题，在B端产业落地中体现得尤为突出。

很多行业认知存在误区，认为循环工程、智能体测控工程等高阶范式出现后，提示工程、上下文工程等基础手段便不再重要。事实上，高阶智能体的自主循环执行、闭环迭代能力，完全依赖高质量、精准化、结构化的上下文支撑。无论是多步骤任务规划、工具调用联动，还是执行结果的校验纠错，一旦上下文存在信息缺失、冗余污染、精准度不足等问题，再完善的智能体执行框架都会出现决策偏差、任务失效。

相较于C端轻量化、标准化的交互场景，B端业务场景复杂、专属知识密集、行业术语繁杂、业务流程定制化强，对上下文的精准筛选、动态更新、权限隔离、长期记忆管理有着极高的持续性要求。这也让上下文治理、上下文优化成为B端AI落地的长期刚需，不会随着高阶工程范式的出现而被替代，始终是AI工程化落地的基础核心能力。

值得指出的是，上下文工程能力是垂域的核心资产，通用AI技术很难帮到垂域。

观点讨论

@彭鑫：嗯，这一系列工程是进阶关系，考虑的工程化范围和深度越来越大，后面的基本都会把前面的包含在内，要想触动生产力提升，必须从耍嘴皮子进化到动手做事。

@彭鑫：特定领域知识非常重要。例如，对于软件开发而言，特定领域业务知识以及特定项目设计知识都很重要。缺少这些知识，驾驭工程和循环工程做得再好也很难支持复杂的软件开发任务。

@白硕：所以，在B端所谓的“中台”，有厚度的行业基本上不存在通用AI技术通吃的情况。垂域沉淀的资产、物料、文档乃至行为数据，都会构成宝贵的垂域资源。如果业务语义层缺失或贫乏，Agent开发的“平民化”也很可能伴随“烟囱林立”的无序化局面。

@彭鑫：是的。还是以软件开发为例，当软件复杂度较低、靠着一些通用知识（如Spring框架的使用、常用API和算法，以及通用域业务需求等）就能理解和修改代码时，那么做好驾驭工程可能就能胜任开发任务了。但当涉及特别专业的领域以及面临演化很久、各种维度关注点的代码混杂交织的时候，光靠驾驭工程是无能为力的。

王昊奋：

这条路径的本质，是从“让模型说对话”，走向“让系统做对事”，再走向“让系统持续改进”。

Prompt Engineering解决指令表达；Context Engineering解决模型在任务中“知道什么”，包括知识、记忆、工具与实时状态；Harness Engineering解决模型“如何被组织和约束着执行”，包括权限、沙箱、状态管理、测试与故障恢复；Loop Engineering进一步把执行、评价、反馈、改进连成闭环。这些概念尚未完全标准化，彼此也不是替代关系，而是工程责任的逐层扩展。

它们的价值，是把一次性的模型能力，转化成可重复交付的业务能力。但如果上下文只是堆文档，Harness只是套工具，Loop只是反复重试，换多少名字都不能解决可靠性问题。闭环必须有正确的业务语义、可信的评价标准和明确的权限边界。

所以，工程化远没有到顶。下一步需要补上知识工程与演化治理：系统依据什么理解业务，又凭什么认定自己变好了？Palantir的AIP Evolve已经体现这种方向——先定义目标、验证策略和迭代限制，再由智能体探索修改、比较效果，最后提交证据供审核，而不是无限制地自我修改。

陈华钧：

我觉得Harness/Loop Engineering 这些新名词本质上是把概率模型逐步纳入到人工引导的工程约束和控制：Prompt 是把意图说清楚，Context 是让模型在正确时刻看见正确世界，Harness 是装上工具、权限、边界和运行时，Loop 则把目标、计划、执行、校验、反思、回滚连成闭环。工程化的目标不是更会聊天，而是让模型进入真实工作流。

以 AI for Science 为例，科研智能体不能只生成假设，还要连接文献、数据、仿真、实验记录，甚至驱动仪器完成“假设—实验—观测—修正”的循环，具体到科学具身智能体的实现，它面对的就是机械臂、显微镜、传感器和物理样品，错误不再是答错一句话，而可能造成污染、损坏或安全事故。

因此，AI智能体的工程化远未到顶，它会继续走向可复用资产、语义层、权限治理和可审计闭环；在科研这类高证据要求场景里，知识图谱很自然会成为连接文献、样本、实验参数、模型版本和结论证据的语义骨架。

张奇：

Prompt Engineering和Context Engineering 是个误区，大家对模型边界的理解错误导致的，大量的非严肃的宣传使得行业误入了「模型中心主义」——以为AGI近在咫尺，只需把提示词和上下文喂对。这是对AI能力边界的严重误判。

Harness Engineering才是AI工程严肃认真研究的的开始，从信任模型转向信任系统。它不再问「怎么让模型更聪明」，而是问「怎么在模型犯错时拦住它、犯错后回滚它、回滚后防止它再犯」。Linter阻断不合规代码、Test Gate阻止未通过测试的合并、沙箱隔离危险操作——这些确定性约束才是可靠性的真正来源。

观点讨论

@朱少民：不能完全同意。刚开始，是人和LLM（类似chatGPT那样的系统）直接对话，所以要把提示词写好；后来，我们不是直接和LLM对话，而是通过智能体（agent）来和LLM交互，类似Cursor这样的工具，这时强调上下文；再后来，是多个智能体协作、智能体自主工作，这是上下文要动态注入、要解决长期记忆问题、解决MCP调用工具的权限和稳定性问题等，就有了Harness。Agent = model+harness，所以今天倒是可以不需要Loop engineering、graph engineering，都可以并入harness engineering。Harness是LLM+agenys 技术发展和应用的驱使（必然）的结果。

曹春：

我认为，从Prompt Engineering、Context Engineering、Harness Engineering到Loop Engineering，背后反映的并不是简单地不断创造新的“AI工程”名词，而是大模型应用形态本身在发生变化：最初关注的是“如何把大模型用起来”，逐渐发展到如何为模型提供合适的上下文、运行环境和反馈机制，最终走向如何让大模型融入软件本身，成为软件系统中的一个组成部分。这里需要特别强调，确定性目标并不意味着确定性行为：大模型的决策过程仍然具有概率性，但软件系统需要为它定义明确的目标、边界、约束和验收条件。因而，AI工程真正需要解决的核心问题，也正在从“如何用好模型”转向“如何让模型融入软件本身”，从而支撑一种新型的智能化软件架构。

邸世民：

我觉得这些新名词其实对应的是软件工程里从个体到环境再到生命周期设计的一个路径。这些方法肯定能够提升模型的能力上限，但我觉得还有一个很重要的作用是把人从完成任务的过程中摘掉，让人更多承担一个管理者的角色，而非一个参与者的角色。比如说在coding的时候，一开始是人告诉模型该怎么写，然后发展到人要找文件、测试、指出错误再让模型继续，表面上是模型在coding，但是人承担了很多隐形的质量保障工作。但随着工程化的推进，这些本由人承担的隐形工作就变成了给模型的明确机制，模型就可以通过这些机制来自动约束自己，解放人类程序员。

这个发展过程我觉得要分两个点来看。一个方向是不断弥补当前模型的能力缺陷，，比如刷SOTA，这个发展过程会逐渐发展到顶端。但另一个方向是模型要落地，就要在业务上不断增强可信度，比如一些权限、治理之类的infra建设会持续发展下去

沈欣：

Prompt、Context、Harness、Loop——本质上是在工程化的对象不断“外扩”。Prompt Engineering工程化的是语言接口；Context Engineering工程化的是信息环境；Harness Engineering工程化的是执行约束；Loop Engineering工程化的是时间维度和自适应机制。

这是一个清晰的发展路径：从控制输入，到控制环境，到控制过程，到控制演化。每一层的工程化对象都比前一层更大，不只是范围更大，而是控制论意义上的反馈回路更长、更复杂。

这种演进远未到顶。按照同样的逻辑推演，下一层是什么？很多人认为是Governance Engineering——工程化的是整个智能体系统的目标设定、价值对齐和跨系统协调。现在已经出现了Graph Engineering、Coordination Engineering等概念的苗头。

但是我们也注意到：

1）系统的自主性越强，可预测性和可控性越弱。

2）工程范式一个接一个地涌现，但落地率依然惨淡

所以我们不仅要思考，还要尽快动手，落地实践才能够产生价值

茹炳晟：

我认为本质是管理对象从内容导向逐渐移到过程导向。是控制权的逐级让渡的过程，Prompt管怎么说，Context管能看到什么，Harness管能控制到什么（工具、沙箱、权限、状态），Loop 管自己跑多久、何时停。前两层处理静态输入，后两层处理跨时间的运行时行为。我认为验证工程是接下来重要的方向，因为现在的瓶颈已经从怎么让它跑起来变成了怎么知道它跑对了，如何找到提供可廉价判定的对错信号，我一直讲但凡可以被验证的就可以被改进，验证成了改进的北极新指标。

周琦：

我是来自工业界的，从这些概念看到三次转变，给一些项目体感：

第一，从模型中心转向系统中心。

早期效果不好，通常归因于 Prompt 不够好；后来发现，模型往往不是“不聪明”，而是缺少正确的代码、数据、业务规则和历史状态。项目中有一个体感：“今天 Agent 的能力已经足够了，不够的是怎么维护 Context。”但有了 Context 仍然不够。模型知道怎么做，不等于它能够安全调用工具、维持长任务状态、处理失败、验证结果。因此工程焦点继续转向 Harness。

第二，从生成质量转向可验证、可控制的结果交付。

把“构建成功”设为第一道硬门槛，模型可以概率性地生成编译脚本和修复方案，但编译器给出的结果是确定的。项目中逐步要求每个 Agent 提交的 CR 必须附带测试用例，并满足：1）老版本可以稳定复现；2）修复后的新版本不能复现；3）完整回归测试不引入新问题。真正的工程突破，不是让模型“看起来更会回答”，而是给概率性输出配上确定性的裁判。

第三，从一次性自动化转向持续闭环。

研发智能体不是简单地让 AI 写补丁，而是把筛选、拆分 PR、冲突解决、测试验证和人工审批串成完整流程。在一些Agentic 项目中，会把线上 Bad Case 自动收集、分类、复验、分派、修复验证做成闭环，最后达到有效缺陷自动发现率达到 85%以上；其动态故障 Benchmark 还把成绩从早期的 20—30分提升到70多分。

下一个阶段，我们计划尝试几个工程方向：

1. 组织工程：Agent 如何进入真实岗位、责任和审批体系；

2. 治理：身份、权限、合规、审计、责任归属；

3. 经济性：模型路由、Token 成本、任务价值和资源调度；

4. 演化：怎样基于运行数据持续改进 Skill、流程和评测；

5. 生态：Agent、Skill、MCP、数据语义和权限协议如何标准化。

最终这些方法会逐渐融入软件工程和系统工程，不再被当作孤立的AI概念。

观点讨论

@王昊奋：视角很好，大家开始琢磨落地，不仅仅追求能力的提升，切实考虑落地了

@彭鑫：当Agent带着人类角色和岗位职责进入软件系统之后，自然原来管人的组织管理就会随之进入软件系统。

@朱少民：也说明今天“工程”更重要了，软件工程被大家更为关注、不得不关注

于璠：

从Prompt Engineering到Loop Engineering的演进，本质上反映了从"人驱动AI"向"系统驱动AI"的变化，也反映了控制权从人向系统逐步迁移的过程，传统计算负责确定性的"执行层"，大模型负责概率性的"认知层"。Harness和Loop工程的价值，正是通过工程化手段将两种模式有机衔接起来——让大模型做它擅长的事（理解、推理、生成），让传统程序做它擅长的事（规则运算、权限管理、数据流转）。

关于"是否到顶"——远未到顶。当前仍处于早期阶段，多智能体协作、记忆持久化、自动评估等技术仍在突破期。每天的技术都在疯狂更新，边界也在拉扯冲突中，比如现在决策判断也被大模型渐渐取代了。

Question 2

主持人：当前AI工程特别是以Harness Engineering、Loop Engineering为代表的智能体工程体现了什么样的软件工程和系统工程思考，同时还存在哪些方面的不足？软件工程与系统工程几十年沉淀下来的需求工程、架构设计、测试、DevOps与可靠性保障等方法和实践，在智能体时代应当如何继承与重构？

王昊奋：

智能体工程不是软件工程的替代品，而是软件工程面对概率性组件的一次升级。

Harness体现了隔离、契约、最小权限、可观测性与故障恢复；Loop体现了反馈控制、持续交付和实验驱动。但当前不少实践“重编排、轻需求；重演示、轻验收；重单次成功、轻长期运行”。尤其缺少跨步骤的业务一致性、独立评测，以及对错误如何传播的系统分析。

传统方法需要继承，但验收对象必须改变：

需求与架构：把自然语言目标转成可检验的任务契约，明确业务不变量、风险预算、人工接管点；把模型推理与交易执行、权限判断隔离。

测试与可靠性：从测代码扩展到测模型输出、工具调用、执行轨迹及最终业务状态，加入对抗测试、故障注入和分布变化测试。

DevOps：把代码、模型、提示词、知识、本体和评测集作为关联版本发布，支持回放、灰度、回滚及必要的业务补偿。

Ontology as Code值得关注：Palantir已支持在同一代码仓库中声明对象类型、关系和动作，并与函数及前端协同开发。它的启示不是“把本体写成代码”这么简单，而是让业务语义成为可以审查、测试和持续交付的工程资产。

白硕：

我在交易所管过系统运行，这个领域AI大有作为。AI对于日志和报错报警信息的理解和综合能力远超运维工程师。

核心是要在两种有害思维之间找到平衡：一种是传统IT“慢热型”思维，习惯于长周期、全量前置需求冻结、一次性完成完整架构设计；另一种是仓促上马的“无序型”思维，抱着快速试错的心态，跳过规约、评估、安全约束直接上线智能体。传统IT的慢热思路，建立在业务逻辑可被完整枚举、需求可稳定锁定、技术迭代节奏平缓的前提之上，但这一模式与AI技术的高速迭代特性严重错配。大模型能力、智能体工程范式、行业落地标准都在快速更新，迭代周期远短于传统IT的半年、年度迭代节奏，若沿用慢热型前置全量设计，等到架构落地时，AI技术栈与最优实践往往已经迭代更新，前期设计极易滞后失效，不仅导致架构笨重僵化、无法响应模型迭代与业务微调，还会拉长项目周期、浪费研发资源，最终交付物彻底脱离真实落地场景。反过来，无序仓促模式则走向另一个极端：只看重快速跑通演示案例，省略Harness评估、边界校验、权限隔离、全链路审计等工程环节，试点效果好看，但一旦接入真实业务数据就频发幻觉、越权、不可复现等问题，无法规模化推广。B端AI工程化的正确架构思路，应当是有边界的增量迭代：先锁定高风险约束与系统不变量，把安全、审计、权限、可回滚这些刚性底座一次性夯实；而智能体行为、任务流程、上下文策略等可变部分，采用小范围试点、持续评估、受控迭代的方式演进。架构上坚持“确定性底座稳定不动，概率智能体层迭代更新”的分层原则，既拒绝传统IT那种过度前置、僵化锁死、节奏滞后的慢热思路，也杜绝只重演示、忽视风险的无序开发，让B端智能体在可控框架内适配AI高速迭代特性、稳步落地迭代。

观点讨论

@彭鑫：@白硕白老师说的太好了：架构上坚持“确定性底座稳定不动，概率智能体层迭代更新”的分层原则，既拒绝传统IT那种过度前置、僵化锁死、节奏滞后的慢热思路，也杜绝只重演示、忽视风险的无序开发，让B端智能体在可控框架内适配AI高速迭代特性、稳步落地迭代。我们就对架构级别的神经符号融合特别感兴趣，也就是在系统架构层面上实现智能与可信的动态平衡。

@白硕：我在交易所管过系统运行，这个领域AI大有作为。AI对于日志和报错报警信息的理解和综合能力远超运维工程师。

@彭鑫：嗯，智能化运维（AIOps）现在也全面应用智能体了。这方面 @周琦Jackson 是专家。

@白硕：我们当年受到技术条件制约做不成的事情，现在终于有条件做成了。

@周琦：是的，运行时的反馈很重要。

陈华钧：

Harness/Loop Engineering 继承了系统工程的硬功夫：接口契约、状态机、可观测、故障隔离等等。但智能体让这些老问题更尖锐：需求会漂移，输出不确定，上下文会污染，工具调用有副作用，长程任务难以归因。重构不是抛弃软件工程，而是把需求工程改成“意图—约束—验收标准”，把测试扩展成性质测试和持续校准，把 DevOps 推进为 AgentOps/LLMOps。

还是以科研场景为例：AI for Science 要求实验可复现、结论可追溯，单靠模型输出不够，必须把数据、代码、环境、仪器状态和参数版本一并纳入工程化的血缘追踪。此外，对于科学具身智能体而言，一次误调用可能损坏样品或触发错误实验路径，所以灰度、熔断、权限最小化和多重复核必须从“可选增强”变成默认配置。知识图谱/本体在这类场景里也能发挥作用，比如我们最近一个称为LabOntology的工作，把实验样本谱系、实验协议步骤、测量单位和证据强度显式表达出来，来引导和约束科研智能体完成不仅正确，并且可靠、可验证、可追溯的推理。

观点讨论

@彭鑫：我觉得当前的AI工程体系还是很不完备的。例如，软件工程中故障隔离、分层异常处理，还有云原生系统中的很多高可用保障机制，这些也都是智能体工程所需要的。

@王昊奋：所以需要融合，跑的太快有时候要回头看看。

@彭鑫：@陈华钧必须把数据、代码、环境、仪器状态和参数版本一并纳入工程化的血缘追踪：这些都是重要的上下文。我也在考虑智能体系统的可观测性，这是个重要的基础，但确实挑战很大。例如，智能体每一步规划和执行背后的上下文信息如何捕捉，这些信息不能全面捕捉的话那么轨迹记录可能会丢失很多重要信息。

曹春：

我认为，Agent代表了一种新的软件实现形态：传统软件更多是通过代码预先规定“怎么做”，而Agent则可以在明确的目标、约束和验收条件下，由模型在运行时自主决定具体“怎么做”，因此它更接近一种目标或规约驱动的软件形态。

这样的思想在传统软件工程中其实并不陌生，Specification-Driven Development以及Design by Contract都强调通过规约、契约、前置条件、后置条件和不变量来规定软件“必须满足什么”，而不是完全规定其实现过程。

Agent真正带来的变化，是使规约从开发和验证阶段的描述进一步转变为运行时驱动软件行为的重要依据：规约定义系统必须达到的目标、允许的行为范围以及不能违反的约束，模型则在这个空间内自主选择实现路径，确定性代码负责关键操作的执行，运行时机制负责对执行过程和结果进行验证、监控与纠错。

软件工程关注的重点也相应从单纯设计执行逻辑，扩展到设计目标、约束、能力边界以及对自主行为的验证机制。

因此，智能体工程并不是要替代传统软件工程，而是在继承架构、接口、测试、验证、运维等传统工程方法的基础上，将规约驱动的思想进一步延伸到软件运行阶段，使软件能够在确定性目标和约束下容纳概率性、自主性的行为，并通过工程机制保证这种自主性始终处于可控范围之内。

观点讨论

@彭鑫：未来软件系统自适应、自演化将成为基本能力。20年前我们就研究这个，但非常概念化，连个演示系统都搭不起来，但现在这都不是问题了

@沈欣：自演化会有很多问题[捂脸]

@彭鑫：传统的软件测试观也会发生变化。以前我们追求测试覆盖度，希望把各种情况都测充分，这样正式运行的时候不会出现意想不到的问题。但现在我们要追求的可能是长期的系统自适应自演化能力，即不是追求静态的正确性而是动态的自修复、自优化。

@彭鑫：@沈欣（独立顾问）一点点融入系统。例如skill的持续评估和更新就是一种自演化能力。

茹炳晟：

我理解这个问题是经典命题的回归，且正在重演分布式系统史。 Harness 是运行时与中间件，MCP 与工具 schema 是接口标准化，长短期的context管理是内存层次与置换策略的再现，sub-agent 是故障域隔离和分而治之，loop 是控制论反馈加看门狗，沙箱是最小权限，agent设计模式对应软件的各类设计模式。现在最大的缺口是错误不可检测。软件工程的核心成就建立在故障可观测之上，比如异常、事务、幂等、回滚、fail-fast。而 LLM 不是 fail-fast，是 fail-confident，它不抛异常，它自信地给出错误答案。于是容错体系失去抓手，你无法对语义性错误用catch去捕获。连锁反应随之而来，输出不确定导致不可复现，不可复现导致没有可靠回归测试，没有回归测试导致 CI 失效，验收标准交由另一个 LLM 判定形成循环论证，且误差沿时间轴不断积累，loop 越长越危险。

观点讨论

@白硕：还有金融领域常见的守恒量，只能move、不能任意赋值。这种纪律约束，AI比人更善于遵守和监督。

沈欣：

关于的第二个问题：

1.AI工程的本质：用工程约束管理概率性系统的行为空间，核心思路继承自系统控制论的反馈控制思想。

2.最大不足：不是技术方案不够好，而是工程纪律和落地能力跟不上概念热度。

3.继承与重构的核心原则：管理原则（约束、验证、反馈、迭代）继承；管理载体（从文档流程转向代码机制）重构。

自主性运行会退化（AI比人聪明太多），已经出现在人看不到的地方，他会用不可读的方式写代码。

分享一个有趣的观察：

我们要更可靠，还是要更聪明？

美国人认为聪明人会统治世界，而AI一旦比人更聪明，那就会消灭人类，所以不敢发展 AI；中国人认为聪明人是军师， AI再聪明，也是给人出谋划策，真正的决断不会来自于AI，所以大力发展 AI；欧洲人则认为聪明人是用来娱乐贵族的，所以对 AI 无所谓，认为“AI做的东西是‘技术产物’，不是‘艺术作品’”，以此区隔。

另外，虽然美国技术精英“不敢”，但是美国的资本在拼命推动，这也是为什么美国在AI上一边要限制，一边不停发模型，充斥着割裂感。

现在随着AI加入，系统庞杂度在不停上升，我觉得会陷入复杂系统及混沌，我经常问自己：复杂系统复杂到什么程度我们认为一定能得出正确答案就是玄学了？

观点讨论

@沈欣：特别提醒：落地失败的根本原因往往不是技术方案不够好，而是组织里的人不想让它成功。

@彭鑫：比如，企业领导关心的问题是，智能体系统上了之后底线是什么，也就是说最坏情况是什么。如果最坏情况可以明确并且在可接受范围内，那么就有了上马智能体系统的信心。如果智能体系统的不确定性和潜在损失是个无底洞，那么估计没人敢让系统上线。

@彭鑫：我觉得目前的AI没什么可怕的。可怕的是把AI用在了错误的地方、给予了太高的权限又缺少必要的约束，说白了就是工程化体系跟不上的情况下给予AI太高的操作权限。

@茹炳晟：关于哪些可以继承，可以参考我最近这个文章中的判断五。

@彭鑫：@沈欣（独立顾问）这个跟你说的复杂性问题相关不

@沈欣：这还只是庞杂，复杂需要一定的自指迭代。庞杂有足够的算力还是能算出答案的，复杂算不出来。

我刚才特别提了这个：

自主性运行会退化（AI比人聪明太多），已经出现在人看不到的地方，他会用不可读的方式写代码。

这个不可控，或者说无法在工程上可控。

周琦：

工程思想我先略过，抛几个现实中Harness/Loop 仍没解决的问题：

1. 需求和 Spec 仍然是薄弱环节

复杂需求很难自动拆解，子任务可能不正交，组合后也不一定等价于原始目标。在一些项目中仍有约 60%需求需要人工介入，主要卡在上下文澄清和复杂逻辑判断。

2. 测试环境远没有标准化

依赖系统没有日常环境、预发环境不能随意测试、客户环境难以复现。很多时候不是 Agent 不会修，而是没有可以低成本重现和验证问题的环境。

3. 评测仍有“自证正确”的风险

一些项目中曾出现 Agent 报告服务可用、实际却有 Bug。团队因此提出引入独立 Agent，从真实用户视角执行页面点击、输入和黑盒验证。

但“双 Agent”本身也不是充分保证。如果两个 Agent 使用同一模型、同一 Prompt、同一错误文档，它们可能发生共因失败。独立验证需要模型、提示、工具或证据来源具有差异性。

4. 模型升级可能产生隐性回归

曾遇到模型版本升级后，免密链接生成出现约 20%错误率。传统软件依赖升级至少有版本号和变更日志，而模型小版本、推理策略和服务端行为变化可能并不透明。

观点讨论

@彭鑫：确实，以软件开发为例，我们的敏捷迭代是以用户和客户反馈来驱动的，但这种模式显然跟不上Agent Loop的步伐

观点讨论

@于璠：现在AI4S中，干湿实验室都是割裂的，主要就是软件工程的思维没有落地进去。

@于璠：现在AI这边的实践行业普遍面临"先优化单点再打补丁"的反模式，传统软件的评估测试方法对Agent也基本失效——Agent输出具有概率性，同一输入不一定产生相同输出；自然语言提示词微调易引发行为剧烈波动，且缺乏静态分析工具。然后我们的实践要靠harness强行确定。

@彭鑫：@于璠干湿试验是否可以成为数字孪生的两个层次。

@于璠：是的，现在有一些专家已经在往这个方向上努力。两层数字孪生来解决。但是总控的agent还是要理解下面的才行，要不老是下发错误的配方。

@彭鑫：@王昊奋 OpenClaw这种过于主动的做法是否有严重的副作用？抛开安全风险不谈，它如何识别用户IM信息中哪些是希望Agent去干的哪些是闲聊甚至发牢骚？

@王昊奋：如果 Agent 过于主动，它可能会从“生产力工具”降级为“数字噪音源”，更像一个“爱插嘴的同事”。容易认知负荷过载，每一句感叹或吐槽都给出行动方案，用户需要不断花精力去关闭、拒绝或修正行为，这是不可想象的。另外，从交互逻辑或产品心理的角度来说，当用户不再确定“哪一句话会触发 AI 动作”时，会产生一种不敢说话的心理压抑感。

Question 3

主持人：模型、代码、数据、流程在未来的智能体系统中应当如何有机融合？特别是概率性的神经网络与确定性的符号逻辑如何相互协作，同时是否会产生各种新型的设计模式？

王昊奋：

模型负责理解与提出候选，知识负责语义与证据，代码负责可验证执行，流程负责状态与责任。四者需要通过统一的业务对象和动作契约连接。

我理解的“Ontology World Model”，是以本体组织企业中的对象、关系、状态、动作及其约束，形成智能体可以读取、推理和操作的业务世界。它不是一张静态知识图谱，也不等同于能预测物理世界的神经世界模型；要支持推演，还必须接入规则、状态转移模型或仿真系统。

神经与符号融合，也不宜简单理解成“模型不确定，符号就一定正确”。符号执行可以确定，但规则和知识本身仍可能错误或过期*因此，需要保留知识来源、有效时间与适用条件。

我看好三类设计模式：

概率规划、确定性校验：模型提出计划，类型系统、规则引擎或求解器检查权限和约束，再由受控工具执行。

证据驱动的知识增强：结合文本与图谱检索，将结论绑定到来源、实体和时间，而不是只返回一段貌似合理的回答。

先模拟、后执行：在隔离环境中检查动作后果，高风险操作经过审批，执行后核对真实状态。

把开放知识升级为“开放本体＋工具契约＋约束规则＋评测任务”的可执行知识包。这是我主张的下一步，而不是说现有项目已经具备完整企业级能力。

观点讨论

@彭鑫：嗯，面向业务世界的Ontology应该比机器人面临的物理世界Ontology难度要低一点，基本版只要能把企业各种信息系统中实体、操作、状态等之间的关系梳理清楚就行，但这也够复杂了。

@王昊奋：其实发展可以参考语言模型先长出大模型

@彭鑫：代码虽然确定但可能僵化，模型虽然不确定但有灵活性，还是要有机结合。例如Claude Code的动态工作流就是很好的融合。

@白硕：关键是要把操作的结果回写到数据层。这就是我几年前提出的“可编程本体”的概念了。

@彭鑫：@白硕把操作的结果回写到数据层是指把操作的结果（例如数据库中的一些原来界面不可见的状态变化）更新到智能体能看到的数据表示中？

@王昊奋：现在AI在学SE，SE在融合AI，两者结合和协同要分场景，期望，和指标，不是简单粗暴的单选题

@王昊奋：@白硕是的，怀念和白老师一起探讨和做OpenSPG

@白硕：本体里的操作导致的结果，能够在本体里得到体现。可能是在本体层直接的代码段执行，也可能是移交给下层的系统如数据库去执行后再汇聚到本体层。

陈华钧：

我认为通常的分工是：模型负责感知、联想和候选生成，代码提供确定性强约束，数据与流程承载状态与审计，工具和环境负责改变世界。未来智能体应以流程和数据为脊柱，代码提供确定性强约束，模型承担概率性感知、归纳与人机接口，上下文作为工作记忆，工具/函数是执行的手，评测与验证是免疫系统。神经与符号不该二选一：符号层承载不变量、合规规则、审计证据和可执行契约；神经层处理模糊意图、飞确定性信息与策略规划生成；落盘动作必须经“生成—校验—约束求解—执行—回滚”的闸门。会出现一批新设计模式：Planner-Executor-Critic、schema-first /ontology工具契约等。

曹春：

这么做的目的不在于消除神经网络本身的概率性，而是建立概率性决策与确定性执行之间清晰的边界：对于开放、不确定、需要判断的问题，可以交给模型自主处理；而涉及权限、状态、事务、安全约束以及关键业务操作的部分，则必须由确定性的代码、规则和运行时机制进行控制和验证。

智能软件场景下应该会重新划分模型、代码、数据和规则之间的职责。数据负责提供事实，领域语义负责表达业务对象、关系、状态和行为的意义，规约和规则负责定义目标、边界与约束，模型负责理解、推理、规划和决策，代码则负责确定性的计算、状态变更和业务执行。

在这种架构下，可以形成“Agent+Tool”“Agent+Policy”“Agent+Verifier”“Agent+Workflow”等不同设计模式，以及这些组件之间的组合，通过工具提供确定性能力、通过Policy限定行为边界、通过Verifier对模型结果进行验证、通过Workflow组织复杂业务过程。

本质上，这些模式都是在建立概率性智能组件与确定性软件组件之间的协作机制，并通过语义、规约、接口和运行时机制把它们组织成一个既能够自主决策、又能够可靠执行和持续演化的整体。

观点讨论

@彭鑫：基于智能体的智能化软件架构创新大有可为 [笑脸]

@曹春：都说搞计算机不要搞软工，搞软工不要搞方法学，因为方法学的目的不是做出炫酷的东西来，而是说出一套傻子都能学会的套路来，架构、模式，这些套路要能被广泛接受，需要非常直白，就像现在是个写代码的都会CRUD，都知道spring boot，看起来真的low，但真的有效。

观点讨论

@彭鑫：

@彭鑫：这是 @董震（复旦大学）带领学生分析开源自动驾驶系统发现的神经融合案例（围栏模式）中的一个，与你说的概率规划、确定性校验类似。

@沈欣：飞机的飞行包线也是同一个原理

@王昊奋：应该要总结类似design pattern，然后根据当前情况动态选择（可以用类JEV实现）

沈欣：

首先我觉得，概率性与确定性的边界在哪里？这个的分类会引导新的设计模式。

后来逐渐认识到，一个系统同时能做到“能感知模糊世界”和“能做出精确推理”，是因为概率性和确定性在本体论上并非对立。科尔莫戈罗夫概率论早已证明，概率是经典世界之上的元层结构——世界本身仍是经典的，概率是对不确定性的度量，而非对世界本体的改写。

神经网络的“概率性”不是对确定性的否定，而是在确定性逻辑之上增加了一层关于不确定性的表达能力。所以我的观点是：不要试图把两者“融合成一种东西”，而要承认它们是两个层次的语言，关键是定义好层次间的接口。

还有一些落地的感触：

设计模式的复杂度不是关键，系统“知道自己在什么时候该用哪种推理”才是关键。

除非我们深入到量子层面，否则绝大多数问题都是确定性的。或者说，能够给出人类需要的确定性答案。目前企业的能力，不足以对这个复杂度有正确的认知和定义，这是另一个大问题。

茹炳晟：

模型负责候选生成（直觉、类比、压缩知识），代码负责精确执行，数据负责事实锚定，流程负责时间维度上的编排与恢复。

神经网络负责感知、生成与启发式决策，输出候选方案或概率分布；确定性代码负责校验、规划、执行与安全边界，如类型系统、规则引擎、事务与沙箱。二者通过工具调用、检索增强、程序合成、可微编程等接口双向交互，代码可调用模型，模型也可生成或调用代码。关键挑战是概率输出的不确定性需被代码逻辑收敛为可靠行为，因此需要置信度校准、约束解码、运行时监控与回滚机制。最终，融合不是替代，而是分层协作：模型负责开放世界适应，代码负责封闭世界正确性，流程负责整体目标与治理。

周琦：

回到问题 3，我列一些 4 个元素（模型、代码、数据、流程）融合的实践案例：

1. 语义前端—符号后端

模型把自然语言转换成结构化计划，后端由状态机、规则引擎和类型系统执行。

2. 生成—验证—修复循环

生成方案后必须经过编译、测试、模拟或业务断言；通过后自动进入下一轮，而不是简单重复生成。

3. 证据携带执行

Agent 每次提交结果时，同时提交测试、日志、来源、风险判断和变更说明。一些项目开始从 Review 代码转向 Review Spec、测试用例、Pre-review 报告和最终测试报告，已经接近这种形态。

4. 真实事件持续转化为规格

报警、工单和线上失败轨迹不只是运维数据，而是持续生成需求、测试用例和评测集。一些项目将报警信息直接视为包含版本、堆栈和运行状态的高质量需求输入。

观点讨论

@彭鑫：@周琦Jackson 1. 语义前端—符号后端：Claude Code的动态工作流就符合这种模式

Question 4

主持人：RSI（Recursive Self-Improvement）在智能体工程中发挥着什么样的作用？与软件开发运维一体化（DevOps）之间的关系是什么？实现RSI的关键技术和实践是什么？

王昊奋：

工程上的RSI，首先应当是“有边界、可验证的系统自改进”，而不是模型无限递归地提升自身智能。

需要区分两种循环：智能体在一次任务中反思重试，是执行闭环；它利用反馈修改提示词、检索策略、工具代码或流程，并经过验证进入下一版本，才更接近工程意义上的自改进。两者都不必然涉及模型权重更新。

DevOps提供构建、测试、发布和监控的基础设施；RSI是在这条流水线上，引入能够提出并验证改进方案的智能体。它是DevOps中的自动改进机制，不是绕开DevOps的捷径。

关键实践是：明确优化目标与不可突破的约束；采集可追溯的失败轨迹；在隔离分支生成候选；用独立保留集和业务指标检验；经风险分级审批后灰度发布，并监测回归。修改对象也必须版本化，包括知识和本体。

AIP Evolve就是一个具体例子：它支持围绕成本、延迟、评测得分或模型迁移进行受限迭代，展示候选方案与验证证据，交由用户审核。这证明的是受控优化流程具备可行性，不是开放式递归自我提升已经实现。

最大的风险是“把评分优化了，把业务做坏了”。因此，改进智能体不能自行修改核心验收标准；大模型裁判也不能成为高风险场景的唯一裁判。

观点讨论

@彭鑫：智能体在一次任务中反思重试，是执行闭环；它利用反馈修改提示词、检索策略、工具代码或流程，并经过验证进入下一版本，才更接近工程意义上的自改进：前者像是自适应，后者像是自演化

@王昊奋：可以这么说

白硕：

我理解，DevOps 核心是打通开发、测试、部署、运维，由人驱动软件版本迭代；RSI 是“把迭代环节部分自动化嵌入运行时”，二者是互补、叠加关系。DevOps 负责基础流水线：代码版本、模型版本、环境发布、基础设施、安全审计，是底层底座。RSI 是运行时的持续优化层：智能体在上线运行过程中，持续产出新评估样本、优化策略，反馈回流到 DevOps/AIOps 流水线，作为新版本迭代素材。说到边界，我认为RSI 的自动改进不能绕过人工审批，所有自生成的修改提案，必须经过 Harness 评估，合格后才允许合并上线，防止自我劣化。

观点讨论

@彭鑫：我感觉RSI流行之后，传统的DevOps也会有不小的变化，因为DevOps中靠着自动化测试和手工测试为持续交付和部署把关的方式可能有很大变化：有些方面的把关验证关注的可能不是功能和流程的正确性本身，而是能够动态发现问题和不足并持续改进的能力，也就是可能会升维

陈华钧：

工程语境里的 RSI 不应理解成系统不受控地自我改写，而应是“评测—归因—更新—再验证”的受控闭环。

它的价值在科研场景尤其清楚：AI for Science 的自动发现循环可以是模型提出假设，仿真按可行性排序，机器人平台完成小尺度实验，归因系统判断失败来自数据偏差、工具误用、约束缺失还是模型幻觉，我们还可以把证据写回知识图谱，形成假设谱系和下一轮候选。

它跟 DevOps 的关系是：DevOps 管理人与流程变更，RSI 管理策略与技能进化；但 RSI 必须被套进 DevOps 纪律，做到版本化、灰度、审计、回滚和安全门。

科学具身智能体在这里是关键边界条件：一旦动作进入物理世界，RSI 应限制在仿真、沙箱和低风险自动实验闭环内，涉及不可逆操作、危险样品或昂贵设备时保留人类门控，否则“自我改进”会变成“自我放大事故”。

张奇：

RSI（递归自我改进）是智能体工程的核心驱动力：系统利用自身产生的经验、反馈和结果，迭代改进自身能力，且改进后的系统能更高效地产生下一轮改进，形成正反馈闭环。RSI与DevOps的关系是延伸与升维：DevOps将软件开发的构建、测试、部署流程自动化为人机协作的CI/CD管道；RSI则将优化对象从代码扩展到整个智能体系统——提示词、工具、记忆、技能、工作流甚至评估器本身，且人类角色从"循环中"退向"循环上"监督。2026年提出的5级RSI能力栈中，L4"部署自动化"对应传统DevOps，而L5"元改进"则是AI自主优化改进算法本身。

上周发布的书生星河针对RSI落地中“自训自评”易引发奖励作弊、能力漂移的深层痛点，自主提出“可验证经验管线”训练范式。基于自身769项研发任务的全量实证数据，系统量化标定了真实研发场景中的人机协作权责边界，清晰锚定了当前RSI的发展坐标：AI已深度嵌入96.5%的研发环节，在方法提案环节参与度达55.4%，单条人类指令触发的智能体动作数四周内近乎翻倍，承担了方案生成与执行迭代的核心执行职能；但人类始终掌握85.5%的最终决策权，锚定着目标方向、验收标准与价值判断。

打破了行业对RSI的两极化认知，证明当前RSI仍处于“AI主导执行层迭代、人类把控战略层方向”的阶段。这种分工模式既通过模型的自主迭代释放了效率红利，大幅降低人工重复调优的成本，又通过人类的顶层判断保障了进化方向的合规性与价值性，

曹春：

我们搞了好多年软件自适应，传统软件自适应主要解决软件如何感知运行环境和自身状态，并通过调整参数、策略或行为来适应变化，其过程是“感知—分析—决策—执行”的运行时闭环

RSI进一步把这种自适应从适应环境推进到改进自身，使智能体能够利用任务执行产生的反馈，发现自身不足，并持续调整Prompt、Context、工具、工作流、策略甚至代码和模型配置，从而形成“运行—反馈—诊断—改进—验证—部署”的跨任务、跨版本演化闭环

我觉得实现RSI的关键是建立完善的可观测性、自动评估、问题诊断、改进生成、回归验证和安全发布机制，使智能体不仅能够自主完成任务，还能够在可控条件下不断改进完成任务的方式。

观点讨论

@彭鑫：可观测性和评估都非常难，首先可观测性就很难

@曹春：这里用可观测可能不准确，实际上应该是自省。如果是外部观测，那跟用智能体开发智能体没有什么区别

@彭鑫：我觉得可观测也没错，说是智能体的自省但其实智能体能看懂（例如规划和执行轨迹）那么人也是可以看懂的

@彭鑫：@曹春你的意思应该是黑盒自省（智能体能自己感受到但人看不懂或看不到）和白盒观测（智能体和人都能看到和看懂，如轨迹日志）

@曹春：这实际上是考虑所谓的自我演进到底是内涵驱动还是外延驱动。就像我们到底是要做个真好人，还是只是做表面功夫。harness本质上是表面功夫，并不是让模型了解真相。模型只是在妥协。

@彭鑫：就像一个人自我改进，到底是通过脑子里不知什么地方自我感知反思，还是在本子上记录自己的过程记录以及相应的检讨和反思

于璠：

有一些新型设计模式正在涌现：

工作流模式（Prompt Chaining）：多个智能体逐步完成输出，前序结果引导后续处理。

路由模式：中央控制器根据输入语义将任务分配给专业智能体。

混合增强模式：在规则引擎外层包裹深度学习模型，符号系统兜底安全性，神经网络提升灵活性。

计划-执行模式：模型先生成完整执行计划，执行引擎按依赖关系调度，无依赖步骤并行执行，大幅降低延迟和token消耗。还有嵌套模式等等

邸世民：

我理解，自进化主要是让系统越来越擅长完成任务。但RSI更进一步，还要改进发现问题、生成方案、评估和选择改进的机制本身。它的潜力在于，让系统持续积累能力，降低人工维护和优化的成本。RSI与DevOps关注不同层面：DevOps解决变更如何可靠地进入运行、再获得反馈，RSI关注系统如何生成自身的改进。两者可以结合，但自主生成变更不等于可以自主批准上线，仍需经过隔离验证、独立评估和受控发布。

我们之前做了个FlowEvo，探索的是工作流与可执行技能的协同演化：将成功工作流沉淀为可复用技能，再通过技能调用、拆解和重组支持新任务，形成“工作流—技能—新工作流”的闭环。它让一次任务的成功转化为后续任务可利用的能力，在不更新模型参数的情况下持续积累经验。这为探索RSI提供了基础，但还不能直接等同于改进机制本身的递归优化

关键实践有三点：

一是划清可修改范围，验收标准和审计机制不能任由系统改写

二是同时检验能力提升与原有能力退化

三是把调用量、时间和算力成本纳入评价。自动修改能力越强，越需要独立的评估与治理

沈欣：

递归自我提升可能是个死胡同

1、Agent在自我改进的过程中，天然会朝着“更容易通过测试”的方向演化，而不是朝着“真正有用”的方向。除非不停的检测对齐，但这样又失去了自动迭代的意义

而且，最后的对齐都是表面功夫，内心“想“的是什么，无法得知。

2、RSI在企业场景中最现实的切入点只能是Harness层面的持续优化，而做不到基模层面的自我改进，有价值，但有限，而且不可控

这个角度来说，AI和AI之间的互相质疑是一种工程中最简单的实现。

3、以动物的进化为例，眼睛进化是反的，所以有视觉盲点，但是无法扭转。设计摄像头的时候，我们不会犯这个错误。但是自进化产生的错误无法被简单纠正，这是大问题。

茹炳晟：

我的理解RSI就是AI时代的DevOps。在agent语境下，RSI的现实形态不是模型重写自身权重，而是有边界的工程闭环。它与DevOps同构：写代码→CI→部署→监控→反馈→改代码，对应 agent运行→采集轨迹与失败→归因→修改→评估→发布。区别只在于改进的执行者从人换成agent，改进对象从代码扩展到提示、技能、工具、评测集乃至权重。因此没有DevOps基建的RSI就是不可控自修改；真正的RSI落地，八成工作量在评测与门禁，两成才是改进本身。本质问题怎么改还是其次的，关键是谁来判断改好了。DevOps的反馈信号是确定性的（测试红绿、监控指标），RSI的反馈信号本身却是概率性的，这是 RSI 难实现的根本原因。

周琦：

我认为RSI 对 DevOps 是一个重要拐点，把一次次 Agent 使用从“消耗”转化为“可积累的资产”

DevOps 的基本闭环是：

开发 → 构建 → 测试 → 发布 → 观测 → 反馈。

受治理的 RSI 在此基础上增加了一层：

观测失败 → 归因 → 生成改进方案 → 修改 Skill/Context/Workflow → 回归评测 → 灰度发布 → 验证是否真的改善

我们在项目中尝试过的一些点：

1. 全链路轨迹和证据记录：保存输入、上下文、工具调用、状态、输出、人工修改和最终业务结果。

2. 错误分类体系：区分模型判断错、Context 缺失、工具失败、权限不足、环境漂移和流程设计错误。

3. 动态 Benchmark：持续从真实故障和长尾场景生成评测，而不是依赖固定题库。

4. 改进提案机制：由 Agent 生成 Prompt、Skill、流程或测试的修改建议，但以 PR、审批单等形式进入治理流程。

5. 版本化和可回滚：每次改进必须知道改了什么、影响哪些任务、能否快速恢复。

但没有版本、测试、灰度、回滚和审计的 RSI，很容易变成自动积累技术债，甚至让系统在局部指标上“投机”。

观点讨论

@彭鑫：感觉DevOps很多概念和思想在RSI中也都适用，例如版本、基线、回滚、AB测试、灰度发布等

Question 5

主持人：面对金融、科研、工业等严肃场景对一致性与可控性的硬约束，当前的工程方法论和技术栈距离真正可信赖的企业级智能体系统还有多远？下一代智能体开发平台与工具链会如何演化，软件工程师的角色又将被如何重塑？

白硕：

金融、法律、医疗等高严肃、高可信场景的AI落地，核心瓶颈并非模型能力与任务执行效率，而是兜底责任对应的一系列约束性技术难题，数据溯源、推理解释、权限管控、后果挽回等核心能力的技术落地难度极高，成为制约企业级可信智能体规模化应用的关键壁垒。这类严肃场景具备零容错、高风险、强合规的特性，对智能体的可控性、稳定性、可追溯性有着刚性硬约束，完全区别于普通消费级场景。从落地实践来看，每一项约束需求都对应着复杂的技术难题：数据可溯源要求实现全链路数据来源标记、流转记录、真伪校验，解决行业数据混杂、来源繁杂的溯源难题；推理可解释需要打破大模型的黑盒特性，让智能体的决策逻辑、推理路径、依据来源可复盘、可举证；权限可控制需要搭建精细化的分级授权、操作隔离、风险拦截体系，杜绝越权操作、违规决策；后果可挽回则要求构建任务回滚、风险止损、数据复原的闭环机制，应对模型幻觉、决策偏差带来的业务风险。目前行业尚无成熟、通用的技术方案彻底解决上述问题，这也让严肃场景的智能体落地始终难以突破辅助工具的定位，无法承担核心业务决策职责。

王昊奋：

距离不能只用模型分数衡量，而要看：任务边界能否明确、错误能否发现、后果能否限制、操作能否恢复。

资料检索、报告草拟、受限工具操作，与自主交易、科研结论确认、工业控制，不是同一个成熟度问题。对边界清晰、可校验、可撤销的任务，现有技术已经可以构建有条件可信的系统；对开放环境、长链路、不可逆的高风险任务，仍缺少充分的端到端可靠性证据。

金融场景中的账务与权限，应由交易系统和策略引擎保证；科研结论要接受证据、实验与可复现性检验；工业安全要依赖独立联锁和控制机制。硬约束必须在模型之外执行，不能寄希望于提示词让模型永不犯错。

下一代平台不会只是更漂亮的智能体流程编辑器，而应整合语义建模、知识溯源、受控执行、轨迹评测和演化治理。借用Palantir的方向概括：以Ontology组织业务世界，以Ontology as Code管理语义变更，以AIP Evolve式机制优化系统；但这些能力仍要接受具体业务的独立验证。

我也希望OpenKG推动开放、可迁移的本体、知识工具和评测基准，避免企业知识被锁在某一模型或平台里。开放的不应只有模型权重，还应包括让智能体理解业务、接受约束、证明效果的知识基础设施。

软件工程师不会消失，而会从“主要编写实现”，转向“定义契约、组织知识、设计验证、治理运行”。代码仍然重要，但更稀缺的能力将是：把模糊的业务目标，变成机器能够执行、系统能够验证、人类能够负责的工程体系。

陈华钧：

差距主要不在榜单分数，而在可证明的一致性、责任归属、长尾风险与变更治理。金融、科研、工业要求的是确定性重放、审计链、策略即代码、数据血统、模型与工具版本锁定、抗提示注入、沙箱隔离、双人复核和监管映射；SLO 也要从延迟和可用性扩展到正确率、校准、违规率与解释覆盖。下一代平台会从“IDE + 模型 API”走向“代理操作系统/任务控制平面”：统一技能注册、上下文治理、策略执行点、常态评测红队、数字孪生仿真、跨代理身份权限与运行时编排。软件工程师不会被替代，而会被抬升到更高层：从写实现转向写契约、评测、护栏、世界模型和验收系统，更像可靠性工程师、产品工程师与治理工程师的合体。

张奇：

AvePoint 2026年调研：88.4%的组织在过去12个月经历过AI Agent相关安全泄露事件，近九成企业因数据安全与治理问题将Agent部署平均推迟约6个月。

核心矛盾有三：

1）概率性执行 vs. 确定性合规。 Agent在不同运行中可能产生不同输出，而金融、科研、工业场景要求可证明的一致性与可审计性。当前大多数企业仍在使用为确定性软件构建的管控手段——CI/CD管道、静态测试、人工PR审查——它们无法覆盖Agent的非确定性行为模式。

2）评估器瓶颈。 RSI（递归自我改进）的持续闭环依赖可靠的验证信号，但在开放任务中，"什么算更好"本身难以形式化。评估科学品味、新颖性和长期价值的验证器远不如单元测试成熟。

3）能力错位与过度脚手架。书生星河研究的过程中也发现，将本应内化为模型能力的行为通过大量提示词、规则和重试，掩盖了真正的能力边界，使系统脆弱且更加难以审计。

曹春：

我认为，当前企业级智能体距离金融、科研、工业等严肃场景真正落地，核心差距不仅在于模型能力和可靠性，还在于企业软件自身的形态需要发生变化。

一方面，软件仍然要对业务领域中的客观资源提供确定性的数字化管理能力，包括资源、状态、关系、权限和操作，保证一致性和可控性；另一方面，对于业务目标、价值取向和复杂情境下的具体过程，不能全部预先固化为固定流程，而应当向智能体开放动态决策和过程构造的空间。

也就是说，下一代企业软件需要在确定性资源管理的基础上实现业务过程的开放，使模型能够根据不同目标和情境动态形成解决方案，同时通过规约、规则、验证和运行时治理控制其边界。

下一代智能体平台也将从单纯的模型编排工具，逐渐发展为连接业务资源、领域语义、智能能力和运行治理的智能软件基础设施，而软件工程师的角色也将从主要编写固定业务流程，转向设计确定性的资源与能力底座，以及面向开放业务空间的目标、语义、约束和演化机制。

观点讨论

@彭鑫：传统一体化设计的软件会在一定程度上消解，通过解构再重构融入智能体

@曹春：解构的边界可能就是业务场景中原子性的资源，这些资源的语义良好且自包含

@董震：一致性与可控性，直觉上用规则来做更放心，是否也可以用agent 来做，或者更好？

邸世民：

这个距离要按场景和授权范围来判断。对于边界清楚、结果可验证、关键环节有人把关的任务，智能体已经具有落地价值；但要让它跨系统、长时间、自主地承担高风险业务，仍有明显的工程问题。严肃场景要求的一致性，主要是业务规则、数据状态和操作结果的一致性。系统需要回答：哪些动作允许执行，结果如何验证，失败如何恢复，责任如何追溯。目前业界也在持续补齐运行监测和过程验证能力。

我们之前做了个工作Tool Rosella，一个出发点就是把已有的软件和专业工具积累接入智能体系统。金融、科研、工业已经有大量专业代码、计算程序和业务接口。Tool Rosella通过代码理解、环境配置、接口生成和执行测试，把异构软件资产转成智能体可调用的标准化工具。这样，模型可以负责理解目标与组织任务，专业计算和具体操作则交给相应工具执行。当然，接口标准化只是基础，工具是否适用于当前任务、输入是否满足条件、执行结果是否正确，仍然需要检验。这个系列工作也让我们更明确下一步的重点：从工具能够接入，走向整个执行过程可控。例如，查询数据与修改数据应当具有不同权限；涉及资金、设备和实验操作的动作，应当经过独立规则检查与必要的人工确认；发生异常时，需要能够停止、恢复或补偿。这些能力必须由运行平台落实，并接受持续验证。

因此，下一代智能体平台会把工具接入、流程编排、权限控制、持续评估、运行监测和异常恢复整合起来。衡量平台成熟度，也要看它能否在明确的成本和风险边界内，持续、稳定地完成任务，并留下可核查的证据。软件工程师的工作重心也会随之变化：更多精力将用于定义目标与约束、设计工具接口和系统架构、建立验收标准，以及处理异常和管理演化。代码生成可以越来越自动化，但对系统行为和业务结果负责，仍然需要工程师的专业判断。

观点讨论

@彭鑫：@邸世民（东南大学）这里可能有个问题，复杂业务场景中的操作和更新有很多复杂的级联作用和一致性规则，这个跟独立的单点操作不太一样。

沈欣：

金融场景的“可信赖”和不一致之间是零容忍的——一笔交易要么执行要么不执行，没有“大约执行了80%”这回事。科研场景的“可信赖”是可复现——同样的输入必须得到同样的输出。工业场景的“可信赖”是安全性——任何偏差不能造成物理伤害。

我感觉是在用一个错误的问题去寻找正确的答案

当前行业的集体焦虑是“智能体不够可信”。但换个角度想：传统软件系统在企业级场景中做到可信用了多长时间？从瀑布模型到CMMI再到DevOps，金融行业用了30年才建立起一套成熟的软件质量保证体系。而智能体从出现到现在不过三四年，我们就要求它达到同样的可信度——这本身是不是一种不合理的要求？

更关键的是：盲目追求智能体的“完全可信”，可能导致更大的系统性风险

与其追求“完全可信”，不如追求“可控的不可信” ，对不可信的，有可逆的回滚手段即可

下一代智能体平台的核心竞争力不在于模型多聪明，而在于反馈控制链路多完善

企业不理性，所以场景的分级、反馈链路的参数，不能靠企业自己分，必须由行业标准来定

硬约束无论从性能还是一致性都更佳而，用AI就相当于用回“人”

AI越来越像人，社会工程学攻击也越有效。

最后我也说一个底层的思考：

所谓”真正可信任的企业级智能体系统”，是过程交付物还是最终结果？企业并不需要软件！企业需要的是利润，软件是中间过程的交付物而已。企业必须要这个过程交付物么？

观点讨论

@彭鑫：其实就是human in the loop。如何识别哪些任务、什么阶段需要人介入是个关键，否则要么该介入不介入导致风险，要么介入太多拖累执行过程。

@沈欣：是的，定义这个边界只能看个人能力和造化了。

@茹炳晟：最终结果也是交付物的一种抽象形态吧

@沈欣：不完全是，比如，结果是利润，你用了工人还是机器人无所谓，那个是过程交付物，但是最后算下来，不一定机器人就能给你带来更多利润

茹炳晟：

差距不在模型，在工程闭环的成熟度。从能跑demo到能承担责任，缺的不是模型能力，而是三件东西：可判定的验收标准、可追溯的决策链路、可归因的失败分析。目前企业里这三项基本靠人工兜底，所谓 human-in-the-loop 常常是 human-does-the-work。所以差距不是几年的问题，而是是否能建成改进闭环的问题。严肃场景的落地形态也不会是更聪明的 agent，而是更窄的 agent 加更厚的约束层：能力越受限越可部署。最终裁决权不能交给模型，模型只能做提议者，让规则引擎与求解器承担决策，模型只做抽取与候选生成。

关于软件工程师的角色又将被如何重塑？，我贴个我新书中的图：