最近有次实践让我对智能体的判断产生了一个变化。当时要处理一批格式混乱的 Markdown 文档三十多篇需要统一标题层级、修正代码块标注、清理无效空格。如果手工处理至少耗掉一个下午如果写脚本又是一堆正则和特殊分支的体力活。我索性把任务描述给一个带终端执行能力的编程智能体让它自己看着办。我一行代码都没写它自己生成了处理脚本运行报错读错误信息改逻辑再运行最后把一份处理报告放在我面前。这个过程中最有价值的不是“省了一个下午”而是它展示了一种正在成型的工作方式智能体不再只是用自然语言描述世界而是直接生成一段能运行的代码用运行结果来验证它对世界的理解。这个思路对应的正是“Code as Worlds”——智能体发现并构建可执行的世界表征。我对这个方向有一个明确的判断智能体的能力拐点不在于它能理解多少自然语言而在于它能不能把对环境的理解、任务目标和操作步骤全部编码成可执行、可验证、可迭代的程序。这句话理解透了后面很多关于智能体选型、使用和排查的问题都会变得清楚。1. 智能体的关键能力不是对话而是把世界变成可执行代码1.1 从“返回答案”到“操作环境”过去很长一段时间里我们接触的技术产品都停留在“问答”模型你输入一个问题系统返回一段文本。聊天机器人、知识库助手、搜索引擎本质上都在做同一件事——从模型知识或文档里检索一段答案然后把它呈现给用户。这类系统有一个共同边界它可以告诉你“这个任务应该这样做”但它不会去执行。智能体的变化是把“回答”升级成了“操作”。它不再止步于解释而是会自己调用终端、读写文件、安装依赖、运行脚本、检查输出再根据输出调整下一步动作。这种变化看起来只是多了几个工具但实际影响是整个交互方式从“获取信息”变成了“完成工作”。这里有一个很容易被忽略的前提智能体要操作环境就必须先对环境有一个模型。环境里有哪些文件依赖是什么哪个命令能解决当前问题执行结果是否达到预期如果这些完全不清楚工具调用就是盲目的。所以操作能力越强的智能体对“世界模型”的依赖就越重。1.2 为什么代码恰好是智能体的“世界语言”如果世界表征的核心是“把环境规则显式地保存下来”那代码几乎是最合适的载体比自然语言合适得多。代码可执行。一段代码写出来后可以直接运行运行的返回码和输出就是环境对它的回应。这个特性让“模型理解是否正确”从主观判断变成了客观验证。代码可追踪。每一步操作都有日志、有退出码、有输出流任务失败时可以回放可以定位是在哪一步出了问题。自然语言的描述做不到这一点——你说的“应该能行”没有运行时反馈。代码可修改。模型对世界的理解出错时改代码比改模型参数要容易得多而且代码修改的影响是局部的这段逻辑错了只影响这段逻辑不会污染其他能力。代码可复用。一段成功描述环境规则的代码可以在后续类似任务里被复用。处理过一批文档之后下一个同类任务可以直接调用已经验证过的脚本。这个组合就是“Code as Worlds”的底层逻辑让智能体用代码来思考世界。自然语言负责表达意图和约束代码负责描述和验证规则。两者缺一不可。2. 什么是“可执行世界表征”它到底解决了什么问题2.1 世界表征不是抽象概念而是一段可运行的程序“世界模型”在强化学习和机器人领域已经存在很多年。传统的智能体要大范围试错才能慢慢从环境反馈中总结出规则。比如让一个机器人学会开门可能要训练几百万步才能在状态和动作之间建立映射。这个映射就是一种世界表征但它藏在高维参数里人类无法直接阅读也无法局部修改。LLM 智能体的根本不同在于它可以先用自然语言和代码做出一个初步的世界模型然后通过执行来校验。这个初步模型不需要完美但它必须是“可运行的”——要么是代码要么是工具调用序列。因为只有可运行环境才能给出真实反馈模型才能被修正。“可执行”是世界表征的关键属性。2.2 从隐式理解到显式可执行大语言模型内部有大量隐式知识知道文件名怎么看、代码怎么组织、常见任务有哪些步骤。但这些知识存在于参数里不验证就无法确认它适不适用于当前环境。我举一个具体例子。你让一个没有执行能力的模型“整理一下项目里的 Python 依赖”它很可能会给你一段文字建议告诉你应该导出 requirements.txt应该检查哪些包。这些建议当然有价值但它不会真的去执行。如果模型有终端工具它就会先跑一个pip list看看实际环境里有什么再决定是输出 requirements.txt 还是重构依赖配置。这就是从“隐式理解”到“显式可执行”的转换。前者是可能性后者是事实。这个转换过程本身就是智能体价值的体现。因为把模糊理解变成可执行程序需要智能体理解目标、理解环境、能写代码、能处理异常——这是一个综合体。能够稳定完成这个转换的智能体才真正称得上“会干活”。2.3 和 RPA、固定脚本的本质区别动态生成与自适应修改传统自动化工具比如 RPA、Shell 脚本、定时任务都具备执行能力。如果只是比“能不能执行”它们甚至比很多智能体更稳定。但它们执行的是人预先写好的固定流程遇到未预期的情况就会失败。RPA 里一个很典型的现象页面按钮的位置变了定位器失效整个流程就断了。要恢复需要人去看新的元素结构改脚本重新上线。这种自动化本质上是把“已知流程”固化下来它没有发现世界的能力。智能体则不同。它可以在每次执行时先观测当前环境再动态生成操作代码遇到失败就读取错误信息并主动修正。同样面对页面变化具备“Code as Worlds”能力的智能体会检查 DOM修改定位逻辑再试一次。它不是预先知道流程而是根据对世界的实时理解来生成流程。这种差异决定了它们适用的任务边界固定流程用 RPA 合适动态变化环境用智能体合适。如果你的任务环境和规则几乎不变引入智能体反而增加不确定性。3. 智能体如何发现和构建可执行世界表征3.1 第一步把环境状态显式观测出来智能体要构建可执行的世界表征前提是具备观测环境的能力。没有观测就没有反馈没有反馈模型就是闭眼走路。不同场景下观测手段不同终端环境pwd、ls、find、git status、node -v、pip list这类命令输出。网页环境DOM 结构、浏览器控制台日志、网络请求、页面截图。API 环境请求参数、响应体、状态码、限流头部信息。实际使用中我发现最容易出现问题的地方不是智能体不会写代码而是它跳过了观测步骤直接凭模型先验知识去执行。比如让它处理某个项目文件它没有先看目录结构就默认文件在同级目录下结果一执行就报“文件不存在”。建议的做法是让智能体在动手前先给出一份“环境快照”列出当前目录、关键文件、依赖版本、运行状态。这一步虽然会多消耗一点 token但能显著降低后续任务的失败率。# 常见环境快照命令示例 pwd ls -la git status --short python --version3.2 第二步把任务目标翻译成可执行代码这一步是核心。智能体需要把高级目标——比如“帮我整理这批文档”——拆解成具体的操作序列读取目录下所有目标文件。抽取出每个文件的标题结构和代码块。定义统一的格式规则。生成转换脚本。运行脚本并对比输出结果。输出一份处理报告。这个拆解过程看起来很简单实际上考验的是模型对任务的理解深度和对环境的建模能力。一个常见的失败模式是任务拆得过大智能体想一口气写完所有逻辑结果中间出错后定位困难。更稳妥的做法是一次只生成一个可验证的子步骤先确认这一步输出对了再继续下一步。我个人的经验是任务描述越具体智能体的成功率越高。如果你只给一句“整理文档”它可能发明出一套你不想要的规则如果你给它明确的文件范围、格式规则和输出要求它的行为会稳定得多。这不是智能体不够智能而是“可执行世界表征”需要一个边界清晰的输入。3.3 第三步用执行—反馈—修正循环让表征长出来真正好用的智能体不是一次就能写出完美代码而是能读懂运行输出并修正。这里有一个非常关键的循环观测环境 → 提出假设世界规则代码 → 执行代码 → 读取返回值 / 错误信息 → 对比预期 → 修正假设 → 重新执行这个循环就是智能体“发现”世界表征的过程。每轮循环之后它对这个环境的理解就变得更准确一点。一开始它可能以为某个函数库已经安装结果一运行发现 ImportError它就知道了这个环境里缺依赖下一步应该先安装。这个知识不是从训练数据里来的而是从当前环境的真实反馈里来的。这里有一个使用上的建议当智能体第一次报错时先不要急着重新描述任务更不要直接替它写答案。给它足够的上下文——让它看错误内容、看它自己生成的脚本——然后允许它自己修正。这个过程往往比“人工接管”更能建立稳定的执行能力。3.4 失败信息是最高质量的“世界知识”为什么说失败信息重要因为模型在训练时学到的是“一般世界的规律”而当前项目里的是“具体世界的约束”。一般世界里可能有 requests 库具体环境里可能没装一般世界里文件路径是相对当前目录具体环境里可能在一个很深的子目录。这些约束只能通过执行失败来暴露。所以智能体在真实任务中遇到的每一个错误——文件不存在、编码不对、依赖缺失、权限不足、端口被占用——都是最高质量的“世界知识”。能正确处理这些错误并在后续步骤中规避同类问题说明智能体已经完成了对当前环境的建模。对使用者来说这个特点也意味着不要追求“智能体一次成功”。一次成功只能说明任务简单或者环境干净。真正值得关注的是它在失败之后有没有能力定位问题、修正假设、重新执行。4. 以终端编程智能体为例从一个最小任务到一套可复用流程现在把上面的思路落到一个具体场景。近一年很流行的终端编程智能体比如 Claude Code 那一类工具就是观察“Code as Worlds”很好的窗口。它们直接运行在终端里能生成代码、执行命令、读取文件行为和在一个真实项目里写代码的工程师高度重合。4.1 前置准备环境、安装和权限检查这类工具通常依赖 Node.js 环境安装方式一般是包管理器。常见的安装流程是# 检查 Node.js 是否已经可用建议使用较新的 LTS 版本 node -v npm -v # 通过 npm 全局安装具体包名以工具官方文档为准 npm install -g anthropic-ai/claude-code安装完成后需要配置 API 访问凭据。不要把密钥写进项目文件更不要提交到版本控制里。首次运行时建议在一个临时项目目录中测试而不是直接放到生产仓库里——这样即使智能体生成了有问题的命令影响也限定在测试目录内。这里还有一个容易被忽略的点权限意识。终端编程智能体的能力是“任意命令都可以跑”这既是它的价值也是它的风险。开始之前先想清楚哪些操作是可以接受的哪些必须人工确认。有些工具自带审批机制建议默认开启尤其是文件删除、数据覆盖、Git 提交这类敏感操作。如果原始工具文档没有明确说明当前版本支持哪些参数落地前要先确认工具的版本和官方使用文档不要照搬网上的旧配置。版本更新频繁的终端工具尤其需要这个习惯。注意不要一上来就把批量数和并发数拉满先用一条样例确认输入、输出和日志都正常。4.2 跑通第一个最小任务把目标交给智能体安装验证无误之后不要急着让它处理复杂项目。先从最小任务开始。假设当前目录下有一些 Markdown 文件我们想统计每个文件里一级标题出现的次数并把汇总结果保存到一个新文件里。可以这样描述任务扫描当前目录下所有 .md 文件统计每个文件内以 # 开头的一级标题数量 把统计结果写入 summary.md格式为“文件名: 数量”。你会看到智能体先执行ls查看现有文件再决定是写一个 Shell 脚本还是 Python 脚本来处理。如果文件数量不多它甚至可能直接用一个循环命令完成。执行完后它通常会在最后输出一段总结告诉你它做了哪些事、产出在哪里。跑通这个最小任务核心目的不是“得到一个统计结果”而是验证三件事智能体能不能观测当前环境。能不能把自然语言目标转化为可执行命令。能不能把执行结果反馈给你。这三件事都正常再进入下一个复杂度级别。4.3 用上下文文件和技能目录让智能体更懂你的项目单次任务跑通之后你会发现智能体对项目的理解有一个明显短板它不记得项目约定。比如项目里规定缩进必须用 4 个空格、不允许直接操作生产数据库、新代码需要写单元测试。这些约定如果不告诉它它就会按通用世界的经验来写。现在主流终端编程智能体的解决方式是引入项目上下文文件比如 CLAUDE.md 这种约定文件。你可以在文件里写清楚项目的技术栈、常用命令、目录结构、编码规范、当前迭代状态。智能体每次运行时会读取它把它作为理解项目的基线。还有一类更进阶的机制叫“技能”Skills通常是以目录为单位的 SKILL.md 定义。你可以把一个重复性任务的执行方法打包成一个技能比如“如何正确运行测试”“如何发布新版本”“如何生成指定的报表格式”。技能一旦定义好后续任务里智能体就能调用不需要每次重新描述。这其实就是“Code as Worlds”理念在项目层面的落地你通过上下文文件和技能目录把项目本身的“世界规则”编码成智能体能直接读取和执行的程序。你维护的不仅仅是一堆说明文档而是一套“关于这个项目的可执行知识库”。4.4 从单次任务走向批量化日志、重试和输出验证单次跑通不等于能稳定批量使用。如果把同一个任务交给 10 个智能体实例处理 100 个文件很快就发现新的问题任务跑到一半超时、某个文件编码不兼容、输出路径权限不足、智能体把之前文件的内容误当成了当前输入。从工程经验看批量化的关键不是并行数而是三个基础设施日志每次执行要有明确的输入、输出、命令调用和错误记录。重试失败任务要有自动或半自动的重试策略并且要避免重复执行已经成功的部分。输出验证每个任务的输出都要有明确的检查环节不能假定智能体说“完成”就是完成。如果你只是偶尔用一次这些缺省无所谓。如果你想把智能体纳入日常生产流程这些工程能力一个都不能少。它们不是智能体本身的能力而是你必须为“可执行世界表征”搭建的护栏。这里补一句比较重要的判断使用终端编程智能体的真正价值不是省掉你写代码的时间而是把一次性的临时任务沉淀成可复用、可验证、可修改的执行流程。如果你每次都用智能体做一件完全不同的事那它只是一个高级工具如果你把常用任务逐步封装成脚本、技能和上下文约定它才会变成一套属于你的自动化体系。5. 智能体执行失败按这个顺序排查智能体在真实环境中执行任务失败率不低。这不是坏事而是环境复杂性的体现。关键是失败后怎么排查。很多人一看到智能体报错就立刻怀疑是模型能力不行或者直接放弃重新换一套工具。实际上大部分失败都可以按下面的层次定位。排查智能体执行失败时第一原则是先不要怀疑模型能力先怀疑输入、环境和权限。大部分失败都发生在这三层。5.1 先看现象任务停在哪一层开始排查前先确定一个问题任务到底是在哪一层失败的完全没有开始智能体可能对任务目标理解不到位或者工具调用入口没选对。执行中报错