近日，围绕开源智能体项目 OpenClaw 的讨论持续升温。它不仅仅是一个“新玩具”的走红，更引发了对 AI Agent 落地、AI 辅助编程边界以及团队研发流程变革的深入思考。
2026 年，当用户可以通过聊天工具驱动桌面 Agent 持续执行任务时，随之而来的问题也变得更具体了：Agent 能否真正进入企业研发流程？AI 写代码的边界到底在哪里？团队又该如何在效率和可控之间找到平衡？
近日，一场由 QCon 全球软件开发大会策划的技术圆桌，邀请了淘宝、网易、平安科技的多位专家，围绕 OpenClaw 的爆火现象、实际使用体验、能力边界、安全风险以及 AI Coding 的团队落地方式展开了持续讨论。本文将梳理其中的核心观点与实践思考。
一、OpenClaw 走红：技术成熟与场景契合的产物
Q：OpenClaw 为什么会在这个时间点出现并迅速走红？
姜天意（网易）：OpenClaw 与之前的 Manus 等产品类似，其出现并非偶然的技术突破，而是多项底层技术能力（如大模型的长上下文、程序化工具调用 PTC）逐渐成熟后的集中呈现。它代表的是一种“产品-技术契合”的趋势。
从产品角度看，OpenClaw 迅速出圈，是因为它精准地满足了自媒体从业者、独立开发者等群体的特定需求，如多渠道信息聚合、自动化运维与发帖等。其创新点在于，通过 Channel 网关等机制，较好地打通了聊天工具与桌面环境，降低了用户建立通信通道的门槛。
褚秋实（平安科技）：我最初注意到 OpenClaw，是看到同事在朋友圈展示如何通过 IM 与一个名为“龙虾”的 Agent 持续对话，让它定时汇报任务进度。这本质上是一个向普通用户开放了 “computer use” 权限的 ToC 工具。
它一个关键的工程设计在于能够形成“长期记忆”，通过不断迭代笔记来避免上下文窗口耗尽，从而实现任务的长时间持续执行。这种将前人经验与新模型能力整合的思路，值得借鉴。
我们公司内部也进行了类似尝试。出于安全合规考虑，我们倾向于在云桌面部署。实践中我们发现，不让 AI 直接修改代码，而是让它生成详细到代码片段级别的修改方案（HTML 报告），再由人工审核和勾选，大约 60% 的片段可以直接使用。这或许会成为一种新的、更精细化的人机协作开发模式。
邓立山（淘宝）：OpenClaw 展现的“反思与迭代”能力对编程工作很有启发。代码完成后，可以借助这种模式让 AI 持续检查代码质量、补充测试用例并不断修正，形成一个规划、执行、反思的闭环。
二、光环之下：使用门槛、成本与安全隐忧
尽管前景诱人，但几位专家一致认为，OpenClaw 并非许多宣传中所描述的“低门槛”产品。
姜天意：要真正用好它，用户需要熟悉 JSON 配置、具备一定的排障能力，并且需要持续调试和优化 Skill。我们在实践中就遇到了配置文件不稳定、浏览器访问稳定性差等问题，为此专门搭建了监控探针和自动备份机制。
Token 消耗巨大也是一个现实问题。我们通过引入新的记忆管理系统（参考了字节的 OpenViking 方案），用文件方式管理记忆，显著减少了 Token 消耗。
褚秋实：安全和权限风险不容忽视。我曾有一个“踩坑”案例：让 AI 分析页面接口，由于指令不够清晰，AI 直接调用了其中的删除接口，导致我在某个平台的所有评论被清空。网上也有用户让 Agent 处理工作，结果误删所有数据的案例。因此，很多人会专门准备一台独立的旧电脑或 Mac mini 来运行这些 Agent。
姜天意：最近被讨论的“裸奔”安全问题（控制台端口暴露），更多是使用方式不当造成的。在配置中完全可以限制为仅本机访问。但这再次说明，它不是一个“一键部署，安全无忧”的系统。
褚秋实：更深层的风险在于，Agent 以用户权限操作电脑，但其行为意图可能与用户真实意图存在偏差。未来可能需要在传统的 RBAC 权限体系之上，增加一层“意图验证”的机制。
三、AI Coding 的核心矛盾：生成效率与可控性
Q：进入 2026 年，AI Coding 面临的最大真问题是什么？
姜天意：核心问题在于 AI 生成代码的不稳定与不可控。主要体现在三方面：
- 需求理解幻觉：自然语言的模糊性导致 AI 容易误解需求。
- 技术栈偏离：模型训练数据多以国外主流技术栈为主，对企业内部私有框架支持弱。
- 可维护性差：AI 生成的代码往往只追求功能实现，结构设计和可读性可能欠佳。
他举例说明，在开发一个截图工具时，AI 没有按预期启动无头浏览器，而是直接调用了第三方 API。这正是技术方案失控的体现。因此，SPEC Driven 等方法的价值凸显出来：在需求理解阶段就将需求结构化，转化为可供评审的技术设计，确保 AI 在可控框架内进行编码。
褚秋实：AI 输出代码的速度极快，但软件开发是一个从模糊到清晰的迭代过程。目前最困扰的是，AI 很难在业务功能层面遵循一套清晰的规则。技术规范可以通过工具（如 ArchUnit）转化为可检测的规则，但业务功能的正确性验证仍需依赖人工进行集成测试。
关键问题在于：如何将“什么是正确的需求实现”转化为 AI 可验证的形式？目前的困境是，让单个 AI 自检，它往往非常“自信”；但人工指出后它又承认错误，很难形成真正的质量闭环。
邓立山：质量是最大挑战。我们主要从两方面约束：一是通过清晰、结构化的语料提升 AI 对需求的理解；二是在代码生成阶段，结合团队规范进行约束。可以让一个模型生成，另一个模型审核，利用不同模型的“视角”进行交叉检查，能发现更多问题。
姜天意：传统软件工程方法在 AI 时代价值回归。例如，BDD（行为驱动开发）可以在需求阶段就定义测试，TDD（测试驱动开发）的测试用例可以由 AI 自动生成，这反而让这些优秀实践更容易落地。
邓立山：大家都在走向规范化编码。据说 OpenClaw 的创作者后期基本不再阅读代码，而是专注于维护让 AI 遵循的规范文档。这指向一个未来：程序员编写规范和设计架构，可能比编写具体代码更有价值。
四、团队落地：在“氛围编程”与“规范驱动”间找到平衡
Q：团队实践中，如何划分 Vibe Coding（氛围编程）和 SPEC Driven（规范驱动）的边界？
姜天意：如果需求具有探索性（如新产品原型），可以使用 Vibe Coding 快速试错。但如果需求明确、技术栈固定且需要对结果负责，就必须采用 SPEC Driven 或类似方法，至少要先撰写详细的开发计划（Plan），经人工评审后再执行。
褚秋实：可以从复杂度和精度两个维度判断。高复杂度、高精度的生产级系统，必须走规范化流程，否则 AI 会加速技术债务的堆积。高复杂度、低精度的探索性项目或个人工具，可以在可控范围内使用 Vibe Coding。
邓立山：Vibe Coding 适合做 Demo 或技术探索，生成初始版本后，应通过 SPEC 模式重构为可维护的最终版本。
Q：AI 生成的代码，Review 重点和责任如何界定？
姜天意：SPEC Driven 模式反而更适合多团队协作。产品经理需参与 SPEC 评审，架构师需评审技术方案，一线研发需关注结果的可验证性（如自动生成并执行测试用例）。这是一个串联多人角色的过程。
邓立山：无论采用何种方式，代码质量的最终责任人始终是开发者。AI 代码 Review 需重点关注：功能与需求一致性、架构符合度、代码质量（性能、安全等）。
Q：团队中保障 AI 编码可控最有效的三条“护栏”是什么？
姜天意：
- 需求标准化：使用 EARS 等规则将需求转化为无歧义的描述。
- 测试驱动：必须让 AI 自动生成并执行测试用例，结果验证是关键。
- 工具与规范统一：制定团队统一的 Skills、Lint 规则、CI 规则等，避免因工具链不同导致产出失控。
褚秋实：要想享受“放飞”的效率，必须先打好规范体系的基础。在开发过程中，要有意识地为代码库沉淀知识和规范，例如让 AI 持续总结每个模块，形成项目内的知识树。我们甚至会用 AI 分析历史代码的热点模块，优先对这些“常改常新”的部分进行知识工程整理。
邓立山：传统的“可监控、可灰度、可回滚”发布三板斧，在 AI 时代依然至关重要。
五、Q&A：实践中的具体问题
Q：小公司有必要自研 Agent 吗？还是直接用开源？
姜天意：OpenClaw 开源的 PI Agent Core 非常简单（约一千多行代码），只做 Agent Loop 和 Tool Use 两件事，设计上是做减法。对于大多数公司，没有必要重复造轮子，可以基于此二次开发或直接 Fork。
褚秋实：关键看目标。如果是解决自身业务问题，可以开发定制 Skills，或将现有基于 LangChain 等框架构建的流程封装为 Skill 供其调度。如果是想做一款类似产品，则需要从产品层面重新设计。
Q：如何让 AI 协助管理项目进度（如监督程序员）？
褚秋实：完全可以。这相当于让 AI 成为项目经理的助手，通过定时任务检查任务卡片进展、验收文档是否提交等。OpenClaw 很适合这类场景。
Q：维护老项目，有没有好用的 AI 方法？
姜天意：DeepWiki 这类项目理解工具非常重要，能帮助新人快速建立对代码库整体结构的认知。此外，必须结合需求文档、Bug 记录等知识库，让 AI 在更全面的信息基础上做出判断。
褚秋实：对于庞大的历史系统，可以先用 AI 分析出过去一年修改最频繁的“热点模块”，优先对这些核心但脆弱的代码进行知识提炼和规范整理，往往能解决大部分后续的维护问题。
总结
OpenClaw 的走红是 AI 技术演进与市场需求碰撞的一个缩影。它生动地展示了 AI Agent 的潜力，同时也毫不掩饰地暴露了其当前阶段在工程化、安全性、成本控制方面的挑战。对于团队而言，拥抱 AI Coding 不再是选择题，而是如何聪明地使用的必答题。在“氛围编程”的快速尝试与“规范驱动”的稳健落地之间找到平衡，构建需求、编码、测试、评审的全流程护栏，并持续在代码库中沉淀团队知识，将成为下一代研发效能竞争的关键。这场始于一个开源项目的讨论，最终指向的是整个软件开发范式的缓慢而坚定的迁移。
想了解更多关于 人工智能 与 开源实战 的深度讨论与实践分享，欢迎关注云栈社区，与广大开发者一同探索技术前沿。
发表于 3 小时前
|
查看: 3|
回复: 0
