AI-Agents

在上一篇文章中，我从 Karpathy 的 autoresearch 项目提炼了一个范式：人写规则，Token 做实验。我们用 AI 客服 Prompt 优化作为案例，验证了这个范式在业务场景中的可行性。但那个方案有一个前提——你需要预先准备评估数据集。

OpenClaw 的场景让我意识到，还有一种更彻底的可能：Agent 用自己的真实执行数据作为评估信号，在用户无感知的情况下持续自我优化。 不需要人工标注测试集，不需要离线批处理，每一次真实使用都是一条训练数据。

1962年，一位伟人为中国工业发展题写了"鼓足干劲，力争上游，多快好省地建设社会主义"。六十多年后，当我们审视AI Agent工程的核心挑战时，会发现一个惊人的对称：Agent工程的终极优化目标，本质上就是对模型Token消耗的"多快好省"。

淘宝用十五年把"多快好省"刻进了中国零售的DNA——商品要多、物流要快、品质要好、价格要省。而今天的AI Agent Runtime，正在用同一套逻辑重塑Token消费——模型类型要多、响应速度要快、完成效果要好、使用成本要省。

悟空——孙悟空七十二变（多）、筋斗云十万八千里（快）、金箍棒降妖除魔（好）、一根毫毛变千猴（省）。一个优秀的Agent Runtime，就是AI时代的淘宝，Token世界的悟空。

企业每天都在产生大量知识，但绝大多数知识从未被记录下来。不是因为没有文档系统，而是因为真正的知识不在文档里，而在产生文档的过程中。

一份产品方案的最终版本只有 10 页，但写这 10 页的过程中，团队讨论了 20 个方案、否定了 15 个、在 3 个关键决策点上反复权衡。这些讨论、推理和决策——才是企业最有价值的知识。传统文档系统只保存了结论，丢掉了思考。

AI Native 文档要解决的，就是这个问题。

很多团队对 Agent 的理解还停留在"LLM + Prompt + 几个工具调用"。这种理解能跑通 Demo，但一旦进入企业级场景——多任务并行、多系统集成、多角色协作、安全审计——就会发现：Agent 系统的核心挑战不是让 LLM 更聪明，而是构建一个可扩展、可治理、可审计的运行时架构。

Agent 系统本质上在解决五个问题：用户要做什么（Agent）、谁来执行（Sub-Agent）、如何执行（Skill）、从哪里获取数据（MCP）、执行过程的状态存在哪里（Workspace）。这五个问题对应了系统的五个核心层次。

本文将这套架构完整展开。

最近在梳理各种 AI Agent 框架和 Runtime 的架构时，我产生了一个越来越强烈的感觉：我们正在重新发明 Unix。

不是比喻。是字面意义上的重新发明。当你把今天主流的 Agent 架构摊开来看——Skill、Workspace、Tool、Pipeline、Orchestrator——你会发现，这些概念和 50 年前 Unix 的设计哲学几乎一一对应。区别只是换了一层 AI 的皮。

传统 IM（即时通讯）解决的是一个简单的问题：让人和人高效地交换信息。文本、图片、文件、语音——三十年来，IM 的核心架构围绕着"谁说了什么"展开，安全靠端到端加密，权限靠静态角色控制，审计靠消息日志。这套体系服务了几十亿用户，足够成熟。

但当 AI Agent 成为 IM 中的活跃参与者——不仅接收消息，还理解意图、调用工具、执行任务、产生后果——传统 IM 的架构假设就被从根本上打破了。IM 不再只是信息传递的通道，而是 Agent 协作与执行的操作系统。

这需要一种全新的 IM 架构。

当我们谈论企业级 AI Agent Runtime 时，第一个需要解决的问题不是"模型有多聪明"，而是"Agent 执行的代码有多安全"。一个能读写文件、执行命令、访问网络的 Agent，如果没有安全边界，就是一颗不知道什么时候会爆炸的定时炸弹。

企业级的 Agent Runtime 首先需要一个安全沙箱：文件系统隔离 + 网络访问隔离。

把一个 AI Agent 拉进钉钉的多个群，是一件非常容易的事情——群管理员点一下"添加机器人"就完成了。但这也是一件极其危险的事情——如果 Agent Runtime 没有做好隔离，你可能正在制造一个企业级的安全事故。

想象这个场景：你的 AI Agent 同时服务于"核心技术架构群"和"外部合作伙伴群"。有人在合作伙伴群里问了一个问题，Agent 的回答中不小心带出了它在架构群里学到的技术方案细节。信息就这样泄露了，而且没有任何人会收到告警。

这不是假设。这是没有隔离的 Agent Runtime 的默认行为。

过去两年，几乎每家企业都在谈"拥抱 AI"。但你去看看大多数企业的 AI 落地项目，会发现一个尴尬的现实：聊天机器人做了一堆，效率提升约等于零。 问题出在哪？不是 AI 不够强，而是企业的数字化基座根本不是为 AI 设计的。

我越来越确信一个判断：AI 时代的企业数字化，可以浓缩成一个公式——

企业数字化 = 工作 Agent 化 + 知识 AI Ready 化 + 软件 CLI 化

这三项缺一不可，而且顺序很重要。

你让 AI Agent 帮你跑一个需要 30 分钟的数据迁移脚本，然后就没了下文——它在干嘛？卡住了？还是已经跑完了？你不知道，因为 Agent 只会在任务彻底完成或彻底失败时才告诉你结果。

这是 Agent 系统中一个普遍的痛点：耗时任务的进度黑洞。用户发出指令后陷入等待，没有进度条，没有中间反馈，只有最终的成功或失败。在 OpenClaw 的实际使用中，我总结了四种适用于不同场景的进度上报方案，每种都有其最佳适用场景。