OpenClaw 之后：AI 系统正在失控还是进化
本文整理自 QCon 北京 2026 圆桌对话《OpenClaw 之后：AI 系统正在失控还是进化》，通过AI音视频转录总结工具Ai好记
进行视频转图文整理，以下为精炼整理后的会议笔记内容。
AI Agent 野蛮生长：软件工程重构、人机协作与安全挑战的全景复盘
当 AI Agent 开始自主决策、跨系统协作、甚至编写代码，软件工程的根基正在被动摇。QCon 北京 2026 的这场圆桌对话，把「失控还是进化」这个选择题，拆成了几个绕不开的技术命题。
失控是进化的前奏，AI Agent 正在经历野蛮生长期
坦率地讲，「失控」这两个字听起来很吓人，但回到技术演进的历史上看，每个新范式都会经历这么一段。
圆桌上几位嘉宾的共同判断是：AI Agent 目前处于典型的「野蛮生长」阶段，就像当年移动互联网刚起步时的 App 生态，乱是肯定乱的，但乱本身就是创新的土壤。
真正值得关注的不是「会不会失控」，而是「失控之后能不能收敛」。
一个关键的分界线在哪儿呢？当 Agent 从辅助工具变成自主执行单元，传统的流程管控手段就失效了。
比如给 Agent 一个「帮我订酒店」的任务，它会自动登录网站、填表、比对价格再到下单，中间跨了四五个系统。
这个过程在人类操作时每一步都有「确认」环节，但 Agent 默认追求效率，确认环节可能被压缩甚至跳过。
这就引出了另一个更深层的问题：软件的架构定义正在被改写。
硅基代码和碳基代码：软件工程的分岔口
这是我今天最想聊的一个观点。
圆桌嘉宾提出，未来软件工程会自然地分成两个分支：
碳基代码工程，面向人类开发者。
你我有认知天花板，一次处理不了太多上下文，所以代码要写清楚、命名要规范、注释要到位、架构要分层。这些原则的本质，是人类认知能力的边界约束。
硅基代码工程，面向 AI Agent。
Agent 写代码跟人类不一样，它不累，不嫌烦，能同时处理几万行代码的上下文。所以传统的代码规范、设计模式对它来说意义不大。但硅基代码有另一个刚需：可验证性和安全边界。Agent 写的代码，人可能看不懂但机器必须能验证，安全策略必须在生成时就内嵌，而不是事后审计。
这两套体系有不同的评价标准。
碳基代码追求可读性和可维护性，硅基代码追求正确性和可验证性。我实际跟几位开发者聊下来，大家对未来的判断其实挺一致的：以后的核心竞争力，不是写不写得出来，而是验证得了验证不了。
那成本这块呢？很有意思，圆桌嘉宾把「质量」和「成本」的关系重新翻了个个儿。
AI 写代码成本趋零，反而是质量提升的转折点
传统软件工程有个铁律：质量越高，成本越高。代码审查、单元测试、安全审计、架构评审，每一样都在烧人力。
但 AI 生成代码的逻辑不一样。Agent 写一万行代码的成本，可能跟人写三行代码差不多。这时候一个反直觉的事情发生了：因为成本足够低，反而可以投入更多精力去做质量保障。
举个例子，Agent 写了一个核心模块，传统做法是人审完就算。但新的做法可以是：先生成 10 个不同版本，全部跑一遍自动化测试和形式化验证，选最优那个上生产。这在纯人力模式下根本不可能，但在 AI 模式下成本可以接受。
圆桌上有人打了个比方：以前是手工小作坊，老师傅小批量生产，品质不稳定。现在是工业流水线，产品数量暴涨但出厂每件都过质检。数量和质量不再是 trade-off，因为边际成本足够低。
但质量只是挑战的一面，另一面是安全。
安全的核心矛盾不是 Agent 不可控，而是边界在失效
说到安全，传统的思路是：把 AI 关在笼子里，不给它权限，不让它碰核心系统。
坦率地讲，这条路走不通了。
为啥呢？因为 Agent 作为数字员工介入实际业务流程时，它的工作方式就不是单点调用了。
一个客服 Agent 可能同时访问 CRM、订单系统、物流平台、退款接口，它在业务流程里横向穿梭。这时候传统的基于角色的权限控制（RBAC）很难套上去。
你给它什么角色？访客、操作员还是管理员？给少了它干不了活，给多了又怕出事。
圆桌嘉宾的核心判断是：安全挑战的本质是「边界失效」。Agent 跨系统、跨组织、跨边界执行任务，传统的安全边界（网络隔离、数据库访问控制、API 鉴权）在 Agent 面前是千疮百孔的。
那怎么办呢？嘉宾们给的方向不是把 Agent 锁死，而是把安全策略从边界设防转向行为审计。
不给 Agent 划一个固定的活动范围，而是让它随时带着一个「行为黑匣子」，每一步操作都有记录、有签名、有审批链。
这就引出了另一个争议性很强的话题：我们到底需要可控的模型还是聪明的模型？
聪明的模型比可控的模型更重要——但前提是得有人兜底
圆桌上有个观点让我印象很深：让聪明人守规矩，比让傻子听话容易多了。
把这个逻辑套到 AI 模型上，就是：与其花大量精力去训练一个「很听话但不太聪明」的模型，不如让模型足够聪明，理解场景、理解上下文、理解规则，然后自己判断该怎么做。
实际测试中，聪明模型在模糊场景下的表现远超「规矩模型」。比如一个客服场景，用户说了一句「帮我查一下我昨天买的那个东西怎么还没到」，聪明模型可以自动理解用户意图、查询订单、判断物流异常、给出合理解释。
而一个可控但笨的模型，可能只会说「请问您能提供订单号吗」。
但聪明不等于放任不管。嘉宾们强调，聪明模型需要配强约束机制——不是约束模型本身，而是约束它的行为边界。比如 Agent 可以自主决策调用哪个 API，但必须经过一个「决策审计层」才能真正发出请求。
那问题来了：如果 Agent 真的出了事，谁负责？
权责对等：谁授权谁负责，工具不背锅
这个问题的答案其实挺清晰的。圆桌嘉宾的共识是：责任归属遵循「权责对等」原则。
翻译成大白话就是：谁让 AI 做的，谁负责。不是 AI 公司负责，不是模型负责，是最终授权和部署这个 Agent 的个人或组织负责。
举个例子，公司把客户订单系统接入了 AI Agent，Agent 因为理解错误下了一个错误订单造成损失。追责的时候，你不能说是大模型厂商的问题，因为是你决定把 Agent 部署到这个场景里的。授权行为本身就是一种风险决策，你要承担对应的责任。
所以嘉宾们的建议是：在部署 Agent 之前，先画清楚「责任图谱」。每个 Agent 能做什么、不能做什么、出事了找谁，在部署的第一天就要定义清楚，而不是出事了再来掰扯。
那回到基础技术层面，有没有什么东西是不会被 Agent「冲垮」的？有，圆桌上提到了一个被忽略的视角。
基础软件的确定性价值：数据库和 OS 才是最后的锚点
当大家都在讨论 Agent 多厉害、AI 多聪明的时候，有一个声音特别清醒：真正支撑这一切的，是那些无聊但确定的基础软件。
数据库、操作系统、文件系统、网络协议——这些东西提供的是契约。你给数据库发一个 SQL，它给你一个确定的结果。你调用 OS 的系统接口，它的行为是可预测的。这种「确定性」在 AI 世界里反而成了稀缺品。
为什么呢？因为 AI 模型本质上是概率性的，同样的输入可能得到不同的输出。但整个技术栈的底座必须是确定性的，否则上层没法做验证和审计。
圆桌上嘉宾的原话是：「Agent 可以飞，但它的跑道必须够稳。」
数据库提供的 ACID 特性、OS 提供的进程隔离和权限管理、网络协议提供的可靠传输——这些东西的确定性价值在 AI 时代不但没有削弱，反而更凸显了。因为你所有想要「控制」Agent 的努力，最终都依托在这层确定性之上。
写在最后：进化的代价
回顾整场圆桌，我感受到的更多的是务实，而不是焦虑。
AI Agent 正在改变软件工程、改变代码的分工、改变安全策略的范式。但变化的方向不是无序的，是有迹可循的：成本下降带来质量提升的机会，聪明模型需要更强的约束框架，责任链条必须提前画好。
说到底，失控和进化可能本来就是一回事。关键不在于能不能控制住 AI，而在于我们愿不愿意重新设计一套适应它的规则体系。
常见问题 FAQ
Q：AI Agent 和传统自动化有什么区别？
A：传统自动化是固定的 if-else 流程，Agent 是自主决策的。Agent 能理解自然语言指令，自动选择工具和路径执行任务，适应性更强但不确定性也更高。
Q：AI 写代码的质量真的能比人类高吗？
A：单看一行代码，人类可能写得更好。但 Agent 可以用极低成本生成大量代码并行验证，从整体看，自动化验证后的代码质量下限反而更高。
Q：为什么说安全边界在失效？
A：Agent 跨系统执行任务，传统按角色划分权限的方式难以适用。Agent 需要同时访问多个系统，给少了干不了活，给多了风险太高。安全策略需要从边界设防转向行为审计。
Q：「权责对等」原则在现实中好落地吗？
A：核心是提前画责任图谱。在部署 Agent 前定义好每条执行路径的授权人和兜底方案，比出了事再掰扯要实际得多。
Q：基础软件的确定性是什么意思？
A：数据库和 OS 提供可预测的行为契约。无论上层多复杂，底层保证每次操作结果一致，这是构建可验证 AI 系统的基础。
以上内容由 Ai好记 转录整理。
Ai好记 是一款音视频转图文笔记的 AI 学习助手，支持解析 B站、抖音、小宇宙等平台链接及本地/网盘的音视频文件，转录后自动生成精华速览、思维导图和结构化笔记，帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。