从 Vibe Coding、决策模型到能够持续演进的智能体：关于下一代软件的一些技术观察

这半年，一个很明显的变化是：把一个软件“做出来”，正在变得越来越容易。

过去要写需求、设计界面、安排开发和测试的事情，现在通过 Vibe Coding，几轮自然语言交互就可能得到一个能运行的应用。它降低了试错成本，让很多原本不值得单独立项的小需求有了解法。这是实实在在的进步。

但看到越来越多这类产品时，始终有个疑问：我们是在创造一种新的软件，还是在用一种新的生产方式，批量制造已有的软件？

这让我们很容易想到一个略显夸张的比喻。如果一种强大的新发动机刚刚诞生，人们很自然会先把它装到马车上。车确实跑得更快了，但后来真正发生变化的，是底盘、道路、运输组织方式，以及人和机器之间的分工。并不是马车改装得不够好，而是新动力最终改变了系统的结构。

AI 对软件的影响，或许也值得从这个角度去看。Vibe Coding 正在解决“软件如何被生产”；下一阶段更有意思的问题，可能是“软件应该怎样运行”。

01｜Vibe Coding 解决的是开发效率，还不是软件形态

今天的软件，基本仍沿用一个熟悉的结构：页面承载功能，功能串成流程，流程由人来理解、推动和收尾。即使用 AI 生成了全部代码，用户依然可能要自己打开五个页面、切换三个系统、判断一次异常，然后点击“提交”。

并不是觉得重构旧软件没有意义。遗留系统的维护、安全、成本和体验问题，本来就值得解决。问题在于，用更低成本复刻“菜单—表单—流程”，并不自动等于 AI 原生软件。

如果任务能够直接表达为一个目标，软件能自行寻找能力、执行允许的步骤、验证结果并在必要时请求人类接管，那么用户面对的就不再只是一个功能集合，而是一个持续工作的智能体系统。

我们更愿意把这两种变化区分开：

• 生产方式的变化：代码更便宜，原型更快，软件更容易被创造。
• 运行方式的变化：任务成为基本单元，系统在权限约束下组织能力、完成结果。

前者已经非常显著；后者才刚刚露出轮廓。

图 1软件工作的三种形态并非互相替代。传统功能仍会存在，但智能体可能逐渐接管跨功能的任务组织与执行。

02｜智能体会成为软件的重要形态，但黑盒可能是最大的阻力

当软件从“供人操作的工具”转向“替人执行的系统”，可信度的来源也会发生变化。过去我们可以检查一个页面有没有按钮；以后则要回答：这个任务究竟是谁做的、调用了什么、依据什么作出判断、出了问题能不能恢复？

这里我们特别关注两个常被混在一起的概念。

• 可发现性（Discoverability），解决的是“智能体如何找到和理解外部能力”。设备控制、工单系统、知识库、另一个 Agent，都应有机器可识别的能力描述、输入输出、权限范围、版本和调用条件。2026 年 Google 发布的 Agentic Resource Discovery 规格，已经在探索工具、技能和智能体的发布、发现与验证。[1]

• 可观察性（Observability），解决的是“执行过程如何被外部验证”。任务轨迹、工具调用、模型与数据版本、关键决策、耗时、成本、失败原因，应形成可审计的证据链。OpenTelemetry 对生成式 AI 调用与工具轨迹的支持，正让这件事从概念走向基础工程能力。[2]

我们认为还可以再加两个词：可接管、可恢复。不确定时能暂停并转交人类；失败时能重试、补偿、回滚，而不是给出一句“任务已完成”便结束。

这并不意味着要展示模型全部内部推理，更不是允许智能体无限发现和调用任何工具。恰恰相反，发现能力与授权使用是两件事；展示执行证据与泄露私有数据，也是两件事。

由此浮现出一个值得探索的软件界面：与其让人不断操作流程，不如让人看见任务状态、证据、异常和接管入口。软件逐步从“操作台”变成“任务驾驶舱”。

03｜决策模型的价值，也许是把大模型从大量固定判断里解放出来

今天很多 Agent 的工作方式是：每走一步，就请大语言模型重新读一遍上下文、解释情况，再决定调用哪个工具。对于陌生、复杂的问题，这种方式很有价值；但对于每天重复数千次的固定任务，它未必是合适的成本结构。

2026 年出现了值得注意的分化：TypeSafe 的 Jev、Liquid AI 的 d1 把重点放在给定状态和候选动作，直接生成结构化判断或选项概率，而不是先写出一长段自然语言。Liquid AI 10 月公布的开放权重 d1 模型，还专门面向端侧部署。[3][4]

它带来的启发，不只是推理更快，而是智能体内部可能出现更清晰的分工：

• 确定性规则处理明确的业务限制、安全边界与硬约束。
• 小型决策模型处理高频、有限选项、允许统计误差且可验证的判断。
• 大语言模型处理复杂解释、陌生情况、长程计划和例外。
• 人类或受控系统负责高风险授权与最终处置。

如果，一个工业设备连续出现异常信号，系统可能先用规则检查是否越过安全阈值，再由小决策模型决定“继续观察、复检、生成工单或请求人工确认”。只有出现无法归类的情况，才交给更大的模型分析手册、日志和历史故障。

这种架构不保证完全无人值守，却有机会减少模型不必要的长推理，也减少人在高频例行任务上的参与。人的注意力被留给真正的例外。

当然，决策模型的概率不是安全证明。厂商的延迟测试不能直接等同于具体设备上的端到端性能，固定动作集以外的情况也必须设置拒绝或升级路径。对毫秒级确定性控制而言，模型判断更不能代替 PLC、安全互锁或实时控制回路。

图 2 AI原生软件架构，是让不同层次的智能承担不同性质的工作。安全边界和执行证据应贯穿全流程。

04｜RAG 与 RL 之间，可能还缺少一种让智能体真正专业化的机制

相比通用聊天，企业智能体最难的部分在于：企业真正重要的知识，未必写在文档里。

一台设备在什么环境下容易误报，一个老客户有哪些隐含要求，某次维护为什么不能照搬标准流程，这些往往藏在历史操作、私人经验和业务逻辑中。

RAG 能把相关资料找出来，但“检索到了知识”并不等于“掌握了处理这类任务的能力”。另一端，微调或强化学习能够影响模型策略，却不适合每出现一条工单就重训一次模型。成本、质量、遗忘与上线风险，都不允许如此简单处理。

这里缺少的，不是一种单独的检索算法，而是一层介于知识调用和模型后训练之间的“经验转化系统”。

不妨暂时叫它Experience Compilation Layer（经验编译层）。这是一个架构设想，而不是已经成熟的统一技术标准。

这一层首先要把三类企业资产分开：

• 私有知识：文档、手册、专家经验、行业规范，适合检索和引用。

• 私有数据：工单、设备状态、历史操作、真实反馈，提供可追溯的事实和结果。

• 私有逻辑：审批条件、业务约束、风险规则、操作程序，其中很多内容应表现为可执行规则或版本化 Skill，而不应该仅仅切片存入向量库。

当一个任务完成时，智能体记录的不应只有对话。更有价值的是：当时是什么状态，采取了什么动作，为什么被允许，结果是否被外部系统证实，在哪些条件下可能失效。随后，通过经验归纳、反例检查、离线评测和灰度部署，才能把有价值的经验固化为新的规则、技能、检索权重或候选策略。

2026 年的 MemRL 研究尝试利用环境反馈更新情景记忆的效用，而不频繁更新基础模型权重；MemHarness 则探索如何根据当前场景重构检索到的经验，避免机械复用。[5][6] 它们还不能证明企业级“经验编译层”已经实现，但至少指向一个相同的问题：知识不是简单存得越多越好，经验能否被正确选择、适配并验证，可能更重要。

图 3｜把私有知识、数据和逻辑连接到真实执行反馈；经验先成为可验证、可回滚的能力，再考虑是否值得做更昂贵的模型后训练。

05｜相比一次性问答，长期运行的智能体为什么更需要 RSI？

这也是我们觉得智能体与云端通用大模型有一个重要差别的地方。

通用大模型面向高度开放的问题空间，而部署在企业或设备上的智能体，往往要在相对固定的业务环境里工作几个月、几年。它会反复遇到相似的设备、人员、异常和任务，也会不断获得真实世界的成功或失败反馈。

如果这样的系统长期重复同一种错误，却无法根据结果改善，那它的“智能”就始终停留在单次推理。

这里容易联想到 RSI（Recursive Self-Improvement，递归自我改进）。严格讲，RSI 意味着系统能够参与改进自身的能力与机制，并不等于简单地把聊天摘要写回记忆。当前工程上更现实的目标，或许是从受约束、可验证的自我演进做起。

我想象中至少有两条不同的闭环：

• 任务闭环：感知状态 → 选择动作 → 调用工具 → 验证结果 → 必要时交接人工。

• 学习闭环：回收执行证据 → 归因成功或失败 → 生成候选改进 → 独立评测 → 授权发布 → 观察新版本有没有退化。

第二条不能由同一个智能体随意完成全部步骤。没有独立评测和回滚的“自我改进”，很容易变成错误的自动放大。Anthropic 2026 年关于长任务智能体的工程实践，也强调把规划、生成与评估拆开，通过外部评测避免系统过度认可自己的结果。[7]

所以我们关心的并不是 Agent 能否宣称自己“会进化”，而是一个更朴素、可以测量的问题：运行一千次之后，它的任务完成率是否提高了？人工介入是否减少了？错误与回滚风险是否仍然受控？

这些指标改善，才意味着智能体真正把经验变成了能力。

图 4｜自我改进不是直接改写生产系统：任务反馈进入经验学习，候选能力只有经过独立评测、审批与灰度，才进入下一个运行版本。

06｜端侧 AI 或许是检验这套逻辑的一个好场景

上述问题在端侧和工业现场显得更具体：设备会产生连续数据，动作有物理后果，网络并不总是可靠，私有数据也未必适合全部送到云端。

端侧的价值并不只是“本地运行一个大模型”。更值得探索的，是让感知、决策、执行和结果反馈在靠近现场的位置形成短闭环，而让云端负责跨设备的知识共享、复杂推理、评测与模型更新。

比如在一台工业边缘 AI 设备上，我们不妨选择一个很窄的场景验证：识别异常、定位相关手册和历史工单、提出有限几种处置选项、在授权后创建工单，并且记录最终维修结果。

最初系统可能仍需要工程师确认大部分步骤；积累到足够多的已验证案例后，再把低风险、规律稳定的动作交给规则或小决策模型。遇到陌生情况继续升级到大模型或人工。每一次自动化比例的提高，都由数据和回归测试来支撑，而不是由一句“模型已经足够聪明”来决定。

这类原型真正值得关注的，不是演示时能跑通多少步，而是四个量：端到端任务成功率、人工介入率、风险事件与回滚率、单位成功任务成本。

如果这些指标能够持续改善，一个长期运行的端侧智能体，才开始表现出与传统软件不同的经济性。

写在最后｜软件的资产，可能正在从代码迁移到“被验证过的经验”

Vibe Coding 仍然会是很重要的工具。它让表达想法、验证产品和交付功能变得便宜，这一点并不需要否认。

只是当越来越多人能生成相似的代码、界面和功能时，我们怀疑软件公司的长期价值会慢慢转移到另一些更难复制的东西上：可被发现的能力、可审计的执行过程、可靠的任务策略，以及从私有数据与真实反馈中积累起来的专业经验。

这也解释了为什么我不太倾向于把“用 Vibe Coding 把今天的软件重写一遍”当成最终方向。它可能是必要的迁移阶段，却未必是下一代软件最值得期待的终点。

回头看那个“新发动机装在马车上”的比喻，第一步改装当然有价值。但我更想知道，当我们不再受原来的车架限制时，会设计出一种什么样的交通系统。

对软件而言，我觉得那个问题正在变得越来越具体：

当代码不再稀缺，软件是否有能力在现实任务中持续做对事情，并从真实结果中逐步变得更专业？

这个问题，可能比“下一款软件能用 AI 多快做出来”，更值得我们继续观察。

参考资料与延伸阅读

[1] Google Developers,Announcing the Agentic Resource Discovery specification, 2026-06-17.https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/

[2] OpenTelemetry,Inside the LLM Call: GenAI Observability with OpenTelemetry, 2026-05-14.https://opentelemetry.io/blog/2026/genai-observability/

[3] TypeSafe AI,Introducing System One Models & Jev, 2026-09-15.https://typesafe.ai/blog/introducing-system-one-models-and-jev

[4] Liquid AI,Open d1: Edge decision models for text, vision, and audio, 2026-10-07.https://www.liquid.ai/blog/d1-open

[5] Zhang et al.,MemRL: Self-Evolving Agents via Runtime Reinforcement Learning on Episodic Memory, 2026.https://arxiv.org/abs/2601.03192

[6] Wu et al.,MemHarness: Memory Is Reconstructed, Not Replayed, 2026.https://arxiv.org/abs/2607.28272

[7] Anthropic,Harness design for long-running application development, 2026-03-24.https://www.anthropic.com/research/harness-design-long-running-apps

[8] Zhao et al.,Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, ICML 2026.https://proceedings.mlr.press/v306/zhao26ax.html

注 芯动力AI，我们会继续分享 大模型、Agent 和具身智能等方面的相关信息。