在最近一段时间的智能体项目开发里有一个概念反复被提起Code as Worlds。直译过来是“代码即世界”更准确的说法是“可执行世界表征Executable World Representation”。这个概念让我重新思考了智能体到底在“理解”什么以及我们如何让 AI 真正对现实环境产生可验证的影响。很多同学在搭建智能体时一开始以为只要写 Prompt、调 API 就行真正深入之后才发现智能体能力的上限往往取决于它对世界状态的建模方式而代码是目前最接近“可执行世界表征”的载体。这篇文章我想围绕这个概念做一个系统拆解从概念讲起对比不同世界表征方式再用一个可以直接运行的 Python 示例演示如何让智能体通过代码读写世界状态最后补充开发智能体时常见的问题和工程建议。无论你是刚接触 Agent 开发还是已经用 Claude Code、Dify、Codex 这类工具写过自动化任务这篇文章都应该能提供一些新的思考角度。1. 从“智能体只会聊天”到“智能体看见世界”1.1 智能体不是聊天机器人很多人对智能体Agent的理解停留在“能对话、能生成文字”的层面。但真正的智能体核心能力是在某种环境中采取行动并观察行动带来的结果。聊天机器人只处理语言输入和语言输出而智能体需要处理的是环境状态、行动指令、反馈信号、目标约束……这些内容不能只靠“对话”承载必须有一种结构化、可操作、可验证的表示方式。举例来说如果一个智能体接到任务“帮我把服务器上超过 90 天未访问的日志文件移动到归档目录”它至少需要知道当前文件的路径、大小、最后访问时间。哪些文件满足条件。移动文件的命令是否执行成功。目标目录是否足够空间。执行后系统状态是否正常。这些信息如果只靠自然语言描述过程会很模糊。但如果你把这些信息映射为“文件系统状态”和“Shell 命令动作”那么智能体就拥有了一套可以执行、可回滚、可验证的世界操作方式。1.2 世界表征智能体对环境的“脑内地图”在人工智能领域“世界表征”World Representation指智能体对所处环境建立的内部模型。这个模型决定了两件事智能体能感知到什么以及智能体认为动作会产生什么结果。传统程序里世界表征就是数据结构。例如电商系统的订单状态、库存数量、用户余额都通过数据库表来管理。程序通过 SQL 语句修改这些数据通过事务保证一致性。这就是一种“可执行世界表征”——世界的状态被编码为结构化数据世界的演化被编码为确定性的操作。现代 AI 智能体的不同之处在于它不再由人类预先编写所有业务逻辑而是让模型根据目标和环境反馈动态生成操作代码。这时世界表征的选择会直接影响智能体的可靠性如果表征是纯自然语言智能体容易产生幻觉。如果表征是结构化数据 可执行代码智能体就能把“理解”落在具体的函数调用、文件修改、API 请求上错误可以被检测和回滚。1.3 为什么是“代码”Code as Worlds 的核心观点是**代码不仅是一种编程语言更是压缩和表达世界状态转换过程的理想媒介。**一个函数、一个类、一个 API 调用本质上都定义了“世界如何从一个状态变为另一个状态”。这与人类使用自然语言描述世界有本质区别。举个例子自然语言说“用户点击支付按钮后系统会扣减余额并创建订单。”可执行代码说def process_payment(user_id, amount, order_id): balance get_balance(user_id) if balance amount: raise InsufficientBalanceError(user_id, balance, amount) deduct_balance(user_id, amount) create_order(order_id, user_id, amount) record_transaction(user_id, order_id, amount)后者精确、可执行、可测试。当智能体学会生成并执行这类代码时它就不仅仅是“谈论世界”而是“操作系统中的世界”。这就是可执行世界表征的意义所在。2. 可执行世界表征的核心概念2.1 从“生成文本”到“生成程序”传统 LLM 应用模式下模型输出自然语言回答而在智能体模式下模型输出的经常是代码、工具调用参数、结构化指令。这种变化带来了一个关键问题模型生成的代码如何被安全地执行可执行世界表征要求代码必须具备几个属性可观测性动作执行后系统状态的变化可以被读取。可逆性出现错误时能恢复到之前的状态。可验证性代码执行前可以进行语法检查、类型检查、权限检查。可组合性简单动作可以组合成复杂任务。这也是为什么现代智能体框架普遍引入“沙盒执行环境”和“工具调用协议”。Claude Code、Codex、OpenCode 这些工具之所以受到关注本质上是它们为模型生成代码提供了受控的可执行环境而不是让模型把代码直接交给你后就不管了。2.2 世界的“状态 - 动作 - 反馈”循环用代码作为世界表征后智能体的运行过程会形成一个稳定循环观察当前状态State通过读取文件、数据库、API 响应或环境变量获取世界现状。决策下一步动作Action由 LLM 根据目标生成一段代码或一次工具调用。执行动作Execute在沙盒或本地环境中运行生成的代码。获取反馈Feedback检查执行结果、错误信息、状态变化。更新世界表征Update将新的状态重新映射回代码可见的数据结构。这个循环与强化学习中的“马尔可夫决策过程”很相似区别在于动作不再是离散的按钮而是由代码表达的任意程序。这极大地扩展了智能体的能力边界。2.3 代码作为世界模型的“压缩格式”一个完整的“世界模型”可能需要描述非常复杂的现实系统比如电商系统、文件系统、工业控制系统。如果全部用自然语言描述信息冗余且不一致如果全部用数学公式描述又难以与软件系统对接。代码是介于两者之间的表达方式。一个典型的例子是“数据库 Schema”CREATE TABLE users ( id BIGINT PRIMARY KEY, balance DECIMAL(12,2) NOT NULL DEFAULT 0, status VARCHAR(20) NOT NULL DEFAULT active );这段 SQL 定义了一个微型的世界用户、余额、状态。任何程序都能通过 SQL 查询和修改这个世界。LLM 学会阅读和生成这种 Schema 后就能对“用户系统”进行推理和操作。这就是“发现可执行世界表征”的过程——智能体通过分析系统结构找到一套能够描述并能影响系统状态的代码化模型。3. 智能体如何“发现”世界表征3.1 静态发现读取代码、配置和文档智能体获取世界表征的第一种方式是静态发现即读取系统中的已有信息项目源码函数签名、类定义、模块依赖。配置文件YAML、JSON、Properties 中的可调参数。数据库 Schema表结构、字段约束。API 文档接口地址、请求参数、返回格式。这些信息本身已经是“代码形式的世界表征”。智能体可以把它们放入上下文Context从而理解系统的工作方式。例如Claude Code 在启动时通常会读取项目目录下的 README、package.json、tsconfig.json 等文件再结合目录结构形成对项目的初步认知。这比单纯让 LLM 猜测项目逻辑要可靠得多。3.2 动态发现执行试探性操作静态信息有时候不够因为真实世界的状态是运行时的不断变化的。智能体需要通过执行一些只读或试探性操作来观察状态df -h查看磁盘空间。git status查看代码仓库变化。SELECT COUNT(*) FROM orders;查看订单量。调用GET /api/v1/health检查服务健康状态。这些操作是“只读”的不会改变世界但能让智能体获得当前世界的快照。一个设计良好的智能体应该先做充分的动态发现再开始有副作用的操作。3.3 表征推理从现象归纳可复用逻辑更高级的智能体不会停留在“看一眼就执行”它会从多轮观察中归纳出系统规则并把规则固化为代码。比如智能体多次观察到系统启动需要先设置环境变量DATABASE_URL。接着执行python manage.py migrate。然后启动应用服务。这些步骤反复出现后智能体可以把它总结为一个脚本或一个函数#!/bin/bash set -euo pipefail export DATABASE_URL${DATABASE_URL:-postgres://localhost:5432/app} python manage.py migrate python manage.py runserver 0.0.0.0:8000这一步非常重要因为它意味着智能体不仅仅是“执行指令”而是在构建自己的世界模型。它发现的不是一条命令而是一段可复用的世界转换规则。4. 动手实现一个“可执行世界表征”最小案例理论讲了不少接下来我们写一个可以直接运行的 Python 案例。这个案例会展示如何把一个简单世界一个待办事项系统编码为可操作的数据结构并让智能体通过代码来“感知”和“改变”这个世界。4.1 项目结构我们先创建一个最小项目目录结构如下agent-world-demo/ ├── world.py # 世界状态定义与操作函数 ├── executor.py # 可执行代码的安全运行器 ├── agent.py # 智能体决策逻辑模拟 LLM 输出 └── main.py # 入口脚本演示完整闭环4.2 定义世界状态world.py我们定义一个简单的任务世界。世界状态包括任务列表每个任务有 id、标题、状态pending / done和优先级。# world.py from dataclasses import dataclass, field from typing import List from enum import Enum class TaskStatus(str, Enum): PENDING pending DONE done dataclass class Task: id: int title: str priority: int 1 status: TaskStatus TaskStatus.PENDING dataclass class WorldState: tasks: List[Task] field(default_factorylist) version: int 0 def add_task(self, title: str, priority: int 1) - int: 添加任务返回任务 ID next_id len(self.tasks) 1 self.tasks.append(Task(idnext_id, titletitle, prioritypriority)) self.version 1 return next_id def complete_task(self, task_id: int) - bool: 完成任务返回是否成功 for task in self.tasks: if task.id task_id: task.status TaskStatus.DONE self.version 1 return True return False def top_pending_task(self): 按优先级取出最紧急的未完成任务 pending sorted( [t for t in self.tasks if t.status TaskStatus.PENDING], keylambda t: (-t.priority, t.id) ) return pending[0] if pending else None def to_dict(self) - dict: 将世界状态序列化为字典便于 LLM 读取 return { version: self.version, tasks: [ { id: t.id, title: t.title, priority: t.priority, status: t.status.value, } for t in self.tasks ], }这里的WorldState类就是“世界的可执行表征”。它把无形的任务状态转化为结构化的 Python 对象并提供了改变世界的方法。LLM 或脚本可以通过调用这些方法“操作系统”。4.3 执行器executor.py为了让智能体生成的代码可以被验证和追踪我们写一个简单的执行器要求所有操作都通过我们定义的方法进行避免直接修改内部数据。# executor.py import ast from typing import Dict, Any class Executor: 将 LLM 生成的 Python 代码在受限环境中执行 def __init__(self, world_state): self.world_state world_state def run(self, code: str) - Dict[str, Any]: # 语法检查 try: tree ast.parse(code) except SyntaxError as e: return {success: False, error: fSyntaxError: {e}} # 允许的全局变量只有 world_state allowed_globals { world_state: self.world_state, } # 准备记录输出 outputs [] allowed_globals[_outputs] outputs try: exec(compile(tree, agent_code, exec), allowed_globals) return { success: True, outputs: outputs, world: self.world_state.to_dict(), } except Exception as e: return {success: False, error: f{type(e).__name__}: {e}}这里用了ast.parse做语法检查并用受限的全局变量字典控制执行上下文。实际项目中应该使用更严格的沙盒方案如 Docker、gVisor、Subprocess 隔离这里只演示最小可运行版本。4.4 智能体决策逻辑agent.py在这份演示代码中我们用一段模拟“LLM 决策”的函数替代真实模型调用。真实项目中这个函数应该对应大模型的自然语言到代码生成过程。为了便于读者运行我们使用规则决策。# agent.py from world import WorldState def plan_next_action(world_state: WorldState, instruction: str) - str: 根据世界状态和用户指令生成一段操作代码。 注意真实项目中这一步由 LLM 完成。 这里用规则模拟便于演示。 state world_state.to_dict() pending_tasks [t for t in state[tasks] if t[status] pending] if not pending_tasks: return print(所有任务都已完成) if 完成 in instruction and pending_tasks: target pending_tasks[0] return f world_state.complete_task({target[id]}) print(完成任务: {target[title]}) if 添加 in instruction: # 从指令中提取简单任务标题 title instruction.replace(添加任务, ).strip() if not title: title 临时任务 priority 2 if 紧急 in instruction else 1 return f task_id world_state.add_task({title}, priority{priority}) print(f新增任务 ID: {{task_id}}) # 默认添加并完成第一个待办 return print(world_state.to_dict()) 这段代码体现了一个重要思路**智能体的决策不是直接修改世界而是生成一段代表“世界转换动作”的代码。**这正好对应了 Code as Worlds 的核心思想。4.5 主流程main.py最后把各部分串联起来演示完整的“观察 - 决策 - 执行 - 反馈”循环。# main.py from world import WorldState from executor import Executor from agent import plan_next_action def show_state(label, world_state): print(f\n {label} ) for t in world_state.tasks: print(f #{t.id} [{t.status.value}] {t.title} (优先级: {t.priority})) def main(): # 初始化世界 world WorldState() world.add_task(学习 Code as Worlds 概念, priority2) world.add_task(写一篇技术博客, priority1) executor Executor(world) steps [ 添加任务 阅读《智能体设计指南》, 完成学习 Code as Worlds 概念, 查看当前世界状态, 完成写一篇技术博客, ] for instruction in steps: print(f\n 用户指令: {instruction}) code plan_next_action(world, instruction) print(f 生成代码:\n{code}) result executor.run(code) if result[success]: print(f 执行成功输出: {result[outputs]}) else: print(f 执行失败: {result[error]}) print(\n最终世界状态:) world_dict world.to_dict() for t in world_dict[tasks]: print(f #{t[id]} [{t[status]}] {t[title]}) if __name__ __main__: main()4.6 运行效果与现象分析在终端执行cd agent-world-demo python main.py预期输出类似 初始世界状态 #1 [pending] 学习 Code as Worlds 概念 (优先级: 2) #2 [pending] 写一篇技术博客 (优先级: 1) 新增任务 ID: 3 任务 #1 已标记为完成 查看世界状态打印所有任务 任务 #2 已标记为完成 最终世界状态: #1 [done] 学习 Code as Worlds 概念 #2 [done] 写一篇技术博客 #3 [pending] 阅读《智能体设计指南》从这个示例中能直观看到“可执行世界表征”的闭环世界状态是结构化的对象智能体通过代码改变状态而状态变化又会影响下一次决策。如果真正接入 LLM只需要将plan_next_action内部的规则替换为将world_state.to_dict()与用户指令一起发送给模型要求模型返回可执行 Python 代码。然后继续用Executor执行并返回结果就构成了一个最简的 Code Agent。5. 理解 Code as Worlds 的工程意义5.1 从“推理型智能体”转向“执行型智能体”当前很多智能体平台强调“推理能力”但真实世界的任务最终需要落在执行上。代码执行的结果是可验证的任务完成就是完成失败就是失败不存在模棱两可。这使得智能体的可靠性评估成为可能。如果把世界表征设计成代码结构每一次动作都能进行单元测试、日志审计和状态回滚这是纯自然语言 Agent 很难做到的。5.2 Tool Calling 与代码生成的边界选择工程实践中智能体并不总是需要生成完整程序。很多场景下调用预定义工具更安全高效。于是我们需要区分两个层次操作方式优点缺点适用场景工具调用Function Calling安全可控参数受限灵活性不足固定业务操作如查订单、发消息生成代码执行表达能力强可处理复杂任务风险高需要沙盒数据处理、脚本生成、探索性分析生成代码后人工确认兼顾安全与灵活打断自动化流程生产环境变更、权限敏感操作领域特定 DSL受限但表达力强需要额外学习成本配置管理、规则引擎一个成熟的智能体系统应该同时支持这几个层次。简单操作走工具调用复杂任务自动生成代码高危操作要求人工审批。这也是 Claude Code、Dify 这类平台重点设计的功能。5.3 世界表征的可逆性与审计引入代码作为世界操作媒介后我们需要重点关注“可逆性”。建议在工程中做到每个会改变世界状态的函数都输出 before / after 快照。对可能修改数据的操作保留 undo 函数。涉及数据库操作时优先使用事务。敏感操作记录审计日志内容包括操作人、时间、执行代码、结果。这些要求在传统后端开发中已经是常识但在智能体开发中经常被忽略。很多智能体项目上线后出现“改错文件”、“误删数据”的严重事故根本原因就是没有把世界操作纳入代码审阅和回滚体系。6. 常见问题与排查思路开发 Code Agent 的过程中团队经常遇到以下几类问题。这里我把高频现象、原因和解决思路整理成表格方便对照排查。问题现象常见原因解决思路调用 API 返回 401 UnauthorizedAPI Key 未配置、过期或权限不足检查环境变量与密钥确认服务账号权限模型生成的代码语法错误上下文窗口不足导致截断或模型能力不够增加重试机制压缩上下文使用更强模型代码执行超时任务循环未终止或资源消耗过大为执行器设置超时时间限制 CPU 和内存生成的代码能运行但结果错误模型对世界状态理解有误或参数名写错将世界状态结构以 JSON 形式显式注入提示词沙盒执行权限不足容器未挂载必要卷或缺少系统依赖检查沙盒环境配置按最小权限逐步放行本地进程崩溃如 0xC0000005环境内存访问越界或依赖冲突检查依赖版本使用隔离容器运行上下文窗口中世界状态过大状态序列化没有裁剪或压缩只传入关键字段增加状态摘要层Agent 反复执行相同的错误操作缺少失败记忆或纠错机制将执行失败信息写回上下文增加反思步骤多智能体协作时状态不一致共享状态没有加锁或版本控制引入乐观锁、版本号或事件溯源机制生成代码尝试访问敏感系统提示词未定义边界缺少安全过滤器在提示词中声明禁止操作清单执行器做策略拦截这套排查思路适用于大多数 Code Agent 项目。核心原则是不要假设生成代码一次成功要为每步都加上验证和回退机制。7. 最佳实践与工程建议7.1 把世界状态“显式化”使用 Code as Worlds 思想时最重要的一点是让世界状态显式可见。不要让模型通过“猜”来理解系统而是主动把状态对象、数据结构、接口签名暴露给它。推荐做法定义状态 Schema并把 JSON 示例放入系统提示词。所有状态变更函数必须以统一前缀命名例如world_add_、world_update_、world_delete_。状态变更记录version或updated_at方便追踪版本。为复杂状态提供摘要函数避免上下文爆炸。7.2 安全边界先于功能开发智能体能够执行代码后安全风险会指数级上升。在项目初期就要确定安全边界禁止操作清单例如禁止删除生产数据库、禁止读取私钥文件、禁止连接未知外部主机。操作分级只读操作自动执行可写操作需要审批危险操作强制人工确认。资源限制为代码执行设置超时、内存限制、网络限制。审计日志完整记录智能体的代码生成、执行结果、用户反馈。合法授权和最小权限原则必须贯穿始终。不要为了一时的便利让智能体获得过大权限。7.3 提示词与代码结构分离有些团队习惯把大量上下文塞进 Prompt结果上下文越来越长效果却越来越差。更稳妥的做法是将“世界状态结构”放在程序代码中由工具调用注入。将“业务约束”放在系统提示词中。将“参考示例”放在少量 few-shot 中。将“领域知识”放在 RAG 数据库或外部文档中。这样模型看到的上下文更精炼决策质量更稳定。7.4 重视可观测性智能体执行过程的可观测性往往被低估。建议为每个智能体任务建立类似 Tracing 的日志任务 ID模型输入截断后模型输出代码执行结果世界状态变化 before / after用户反馈或人工干预记录有了这些数据你能在智能体行为失控时精准定位问题也能用失败数据微调模型或提示词。7.5 渐进式自动化许多智能体项目失败是因为团队试图一次性完成全自动闭环。更稳妥的策略是“渐进式自动化”第一步智能体只做分析和建议由人执行。第二步智能体生成代码人在沙盒环境运行。第三步智能体在测试环境自动运行结果由人复核。第四步智能体在生产环境运行低风险任务保留审批。第五步高风险任务也交由智能体自动执行但必须配备完备的回滚机制。在这个过程中智能体逐步获得对“可执行世界表征”的掌控团队也积累了足够多的运行数据和安全经验。7.6 关于主流工具的一点点提示当前社区里讨论较多的 Claude Code、Dify、Codex、Kimi Code 等工具本质上都在为用户构建“智能体发现并操作世界”的通道。这些工具版本迭代极快安装方式、API 参数、平台策略经常变化。建议在使用时遵循以下原则以官方文档为准不要轻信网络上的“一键安装脚本”。不要盲目执行从网上复制下来的未知命令尤其是涉及修改系统配置、安装二进制文件的命令。涉及 API Key 的配置务必通过环境变量或密钥管理服务注入不要硬编码进代码和配置文件。网络上的报错信息不一定是你的环境问题先复现、再排查、后处理。8. 从 Code as Worlds 到更复杂的智能体系统如果你理解了本文的示例和工程思路下一步可以沿着这些方向深入多智能体协作多个智能体共享同一个“世界状态数据库”通过事件消息协作。这时需要重点设计状态一致性和并发控制。长期记忆与学习智能体把过去执行的代码片段沉淀为“技能库”在面对类似任务时直接复用。这与“让智能体发现可执行世界表征”一脉相承。领域专用世界模型针对特定业务如工业控制、金融风控、电商运营构建专属状态对象和操作原语让 LLM 只生成符合领域约束的代码。世界模型评测建立仿真环境自动评测智能体对不同世界状态的感知、决策和执行质量。这是未来 Agent 工程的重要方向。回到最初的问题智能体到底在“理解”什么Code as Worlds 给出的答案是智能体理解的内容是一组可以被代码读写、执行和验证的世界状态与状态转换规则。代码越接近世界的真实结构智能体的行为就越可靠。当你在开发智能体时不妨先问自己几个问题我要操作的世界有哪些关键对象这些对象的状态如何变化哪些动作需要被记录和回滚如何让模型“看见”当前状态把这些想清楚再写代码智能体会变得稳健得多。希望这篇文章能给你一些启发也欢迎在实际项目中尝试“用代码构建世界”的做法对比一下与传统 Prompt 工程的差异。
Code as Worlds：让智能体通过代码理解并操作系统世界
在最近一段时间的智能体项目开发里有一个概念反复被提起Code as Worlds。直译过来是“代码即世界”更准确的说法是“可执行世界表征Executable World Representation”。这个概念让我重新思考了智能体到底在“理解”什么以及我们如何让 AI 真正对现实环境产生可验证的影响。很多同学在搭建智能体时一开始以为只要写 Prompt、调 API 就行真正深入之后才发现智能体能力的上限往往取决于它对世界状态的建模方式而代码是目前最接近“可执行世界表征”的载体。这篇文章我想围绕这个概念做一个系统拆解从概念讲起对比不同世界表征方式再用一个可以直接运行的 Python 示例演示如何让智能体通过代码读写世界状态最后补充开发智能体时常见的问题和工程建议。无论你是刚接触 Agent 开发还是已经用 Claude Code、Dify、Codex 这类工具写过自动化任务这篇文章都应该能提供一些新的思考角度。1. 从“智能体只会聊天”到“智能体看见世界”1.1 智能体不是聊天机器人很多人对智能体Agent的理解停留在“能对话、能生成文字”的层面。但真正的智能体核心能力是在某种环境中采取行动并观察行动带来的结果。聊天机器人只处理语言输入和语言输出而智能体需要处理的是环境状态、行动指令、反馈信号、目标约束……这些内容不能只靠“对话”承载必须有一种结构化、可操作、可验证的表示方式。举例来说如果一个智能体接到任务“帮我把服务器上超过 90 天未访问的日志文件移动到归档目录”它至少需要知道当前文件的路径、大小、最后访问时间。哪些文件满足条件。移动文件的命令是否执行成功。目标目录是否足够空间。执行后系统状态是否正常。这些信息如果只靠自然语言描述过程会很模糊。但如果你把这些信息映射为“文件系统状态”和“Shell 命令动作”那么智能体就拥有了一套可以执行、可回滚、可验证的世界操作方式。1.2 世界表征智能体对环境的“脑内地图”在人工智能领域“世界表征”World Representation指智能体对所处环境建立的内部模型。这个模型决定了两件事智能体能感知到什么以及智能体认为动作会产生什么结果。传统程序里世界表征就是数据结构。例如电商系统的订单状态、库存数量、用户余额都通过数据库表来管理。程序通过 SQL 语句修改这些数据通过事务保证一致性。这就是一种“可执行世界表征”——世界的状态被编码为结构化数据世界的演化被编码为确定性的操作。现代 AI 智能体的不同之处在于它不再由人类预先编写所有业务逻辑而是让模型根据目标和环境反馈动态生成操作代码。这时世界表征的选择会直接影响智能体的可靠性如果表征是纯自然语言智能体容易产生幻觉。如果表征是结构化数据 可执行代码智能体就能把“理解”落在具体的函数调用、文件修改、API 请求上错误可以被检测和回滚。1.3 为什么是“代码”Code as Worlds 的核心观点是**代码不仅是一种编程语言更是压缩和表达世界状态转换过程的理想媒介。**一个函数、一个类、一个 API 调用本质上都定义了“世界如何从一个状态变为另一个状态”。这与人类使用自然语言描述世界有本质区别。举个例子自然语言说“用户点击支付按钮后系统会扣减余额并创建订单。”可执行代码说def process_payment(user_id, amount, order_id): balance get_balance(user_id) if balance amount: raise InsufficientBalanceError(user_id, balance, amount) deduct_balance(user_id, amount) create_order(order_id, user_id, amount) record_transaction(user_id, order_id, amount)后者精确、可执行、可测试。当智能体学会生成并执行这类代码时它就不仅仅是“谈论世界”而是“操作系统中的世界”。这就是可执行世界表征的意义所在。2. 可执行世界表征的核心概念2.1 从“生成文本”到“生成程序”传统 LLM 应用模式下模型输出自然语言回答而在智能体模式下模型输出的经常是代码、工具调用参数、结构化指令。这种变化带来了一个关键问题模型生成的代码如何被安全地执行可执行世界表征要求代码必须具备几个属性可观测性动作执行后系统状态的变化可以被读取。可逆性出现错误时能恢复到之前的状态。可验证性代码执行前可以进行语法检查、类型检查、权限检查。可组合性简单动作可以组合成复杂任务。这也是为什么现代智能体框架普遍引入“沙盒执行环境”和“工具调用协议”。Claude Code、Codex、OpenCode 这些工具之所以受到关注本质上是它们为模型生成代码提供了受控的可执行环境而不是让模型把代码直接交给你后就不管了。2.2 世界的“状态 - 动作 - 反馈”循环用代码作为世界表征后智能体的运行过程会形成一个稳定循环观察当前状态State通过读取文件、数据库、API 响应或环境变量获取世界现状。决策下一步动作Action由 LLM 根据目标生成一段代码或一次工具调用。执行动作Execute在沙盒或本地环境中运行生成的代码。获取反馈Feedback检查执行结果、错误信息、状态变化。更新世界表征Update将新的状态重新映射回代码可见的数据结构。这个循环与强化学习中的“马尔可夫决策过程”很相似区别在于动作不再是离散的按钮而是由代码表达的任意程序。这极大地扩展了智能体的能力边界。2.3 代码作为世界模型的“压缩格式”一个完整的“世界模型”可能需要描述非常复杂的现实系统比如电商系统、文件系统、工业控制系统。如果全部用自然语言描述信息冗余且不一致如果全部用数学公式描述又难以与软件系统对接。代码是介于两者之间的表达方式。一个典型的例子是“数据库 Schema”CREATE TABLE users ( id BIGINT PRIMARY KEY, balance DECIMAL(12,2) NOT NULL DEFAULT 0, status VARCHAR(20) NOT NULL DEFAULT active );这段 SQL 定义了一个微型的世界用户、余额、状态。任何程序都能通过 SQL 查询和修改这个世界。LLM 学会阅读和生成这种 Schema 后就能对“用户系统”进行推理和操作。这就是“发现可执行世界表征”的过程——智能体通过分析系统结构找到一套能够描述并能影响系统状态的代码化模型。3. 智能体如何“发现”世界表征3.1 静态发现读取代码、配置和文档智能体获取世界表征的第一种方式是静态发现即读取系统中的已有信息项目源码函数签名、类定义、模块依赖。配置文件YAML、JSON、Properties 中的可调参数。数据库 Schema表结构、字段约束。API 文档接口地址、请求参数、返回格式。这些信息本身已经是“代码形式的世界表征”。智能体可以把它们放入上下文Context从而理解系统的工作方式。例如Claude Code 在启动时通常会读取项目目录下的 README、package.json、tsconfig.json 等文件再结合目录结构形成对项目的初步认知。这比单纯让 LLM 猜测项目逻辑要可靠得多。3.2 动态发现执行试探性操作静态信息有时候不够因为真实世界的状态是运行时的不断变化的。智能体需要通过执行一些只读或试探性操作来观察状态df -h查看磁盘空间。git status查看代码仓库变化。SELECT COUNT(*) FROM orders;查看订单量。调用GET /api/v1/health检查服务健康状态。这些操作是“只读”的不会改变世界但能让智能体获得当前世界的快照。一个设计良好的智能体应该先做充分的动态发现再开始有副作用的操作。3.3 表征推理从现象归纳可复用逻辑更高级的智能体不会停留在“看一眼就执行”它会从多轮观察中归纳出系统规则并把规则固化为代码。比如智能体多次观察到系统启动需要先设置环境变量DATABASE_URL。接着执行python manage.py migrate。然后启动应用服务。这些步骤反复出现后智能体可以把它总结为一个脚本或一个函数#!/bin/bash set -euo pipefail export DATABASE_URL${DATABASE_URL:-postgres://localhost:5432/app} python manage.py migrate python manage.py runserver 0.0.0.0:8000这一步非常重要因为它意味着智能体不仅仅是“执行指令”而是在构建自己的世界模型。它发现的不是一条命令而是一段可复用的世界转换规则。4. 动手实现一个“可执行世界表征”最小案例理论讲了不少接下来我们写一个可以直接运行的 Python 案例。这个案例会展示如何把一个简单世界一个待办事项系统编码为可操作的数据结构并让智能体通过代码来“感知”和“改变”这个世界。4.1 项目结构我们先创建一个最小项目目录结构如下agent-world-demo/ ├── world.py # 世界状态定义与操作函数 ├── executor.py # 可执行代码的安全运行器 ├── agent.py # 智能体决策逻辑模拟 LLM 输出 └── main.py # 入口脚本演示完整闭环4.2 定义世界状态world.py我们定义一个简单的任务世界。世界状态包括任务列表每个任务有 id、标题、状态pending / done和优先级。# world.py from dataclasses import dataclass, field from typing import List from enum import Enum class TaskStatus(str, Enum): PENDING pending DONE done dataclass class Task: id: int title: str priority: int 1 status: TaskStatus TaskStatus.PENDING dataclass class WorldState: tasks: List[Task] field(default_factorylist) version: int 0 def add_task(self, title: str, priority: int 1) - int: 添加任务返回任务 ID next_id len(self.tasks) 1 self.tasks.append(Task(idnext_id, titletitle, prioritypriority)) self.version 1 return next_id def complete_task(self, task_id: int) - bool: 完成任务返回是否成功 for task in self.tasks: if task.id task_id: task.status TaskStatus.DONE self.version 1 return True return False def top_pending_task(self): 按优先级取出最紧急的未完成任务 pending sorted( [t for t in self.tasks if t.status TaskStatus.PENDING], keylambda t: (-t.priority, t.id) ) return pending[0] if pending else None def to_dict(self) - dict: 将世界状态序列化为字典便于 LLM 读取 return { version: self.version, tasks: [ { id: t.id, title: t.title, priority: t.priority, status: t.status.value, } for t in self.tasks ], }这里的WorldState类就是“世界的可执行表征”。它把无形的任务状态转化为结构化的 Python 对象并提供了改变世界的方法。LLM 或脚本可以通过调用这些方法“操作系统”。4.3 执行器executor.py为了让智能体生成的代码可以被验证和追踪我们写一个简单的执行器要求所有操作都通过我们定义的方法进行避免直接修改内部数据。# executor.py import ast from typing import Dict, Any class Executor: 将 LLM 生成的 Python 代码在受限环境中执行 def __init__(self, world_state): self.world_state world_state def run(self, code: str) - Dict[str, Any]: # 语法检查 try: tree ast.parse(code) except SyntaxError as e: return {success: False, error: fSyntaxError: {e}} # 允许的全局变量只有 world_state allowed_globals { world_state: self.world_state, } # 准备记录输出 outputs [] allowed_globals[_outputs] outputs try: exec(compile(tree, agent_code, exec), allowed_globals) return { success: True, outputs: outputs, world: self.world_state.to_dict(), } except Exception as e: return {success: False, error: f{type(e).__name__}: {e}}这里用了ast.parse做语法检查并用受限的全局变量字典控制执行上下文。实际项目中应该使用更严格的沙盒方案如 Docker、gVisor、Subprocess 隔离这里只演示最小可运行版本。4.4 智能体决策逻辑agent.py在这份演示代码中我们用一段模拟“LLM 决策”的函数替代真实模型调用。真实项目中这个函数应该对应大模型的自然语言到代码生成过程。为了便于读者运行我们使用规则决策。# agent.py from world import WorldState def plan_next_action(world_state: WorldState, instruction: str) - str: 根据世界状态和用户指令生成一段操作代码。 注意真实项目中这一步由 LLM 完成。 这里用规则模拟便于演示。 state world_state.to_dict() pending_tasks [t for t in state[tasks] if t[status] pending] if not pending_tasks: return print(所有任务都已完成) if 完成 in instruction and pending_tasks: target pending_tasks[0] return f world_state.complete_task({target[id]}) print(完成任务: {target[title]}) if 添加 in instruction: # 从指令中提取简单任务标题 title instruction.replace(添加任务, ).strip() if not title: title 临时任务 priority 2 if 紧急 in instruction else 1 return f task_id world_state.add_task({title}, priority{priority}) print(f新增任务 ID: {{task_id}}) # 默认添加并完成第一个待办 return print(world_state.to_dict()) 这段代码体现了一个重要思路**智能体的决策不是直接修改世界而是生成一段代表“世界转换动作”的代码。**这正好对应了 Code as Worlds 的核心思想。4.5 主流程main.py最后把各部分串联起来演示完整的“观察 - 决策 - 执行 - 反馈”循环。# main.py from world import WorldState from executor import Executor from agent import plan_next_action def show_state(label, world_state): print(f\n {label} ) for t in world_state.tasks: print(f #{t.id} [{t.status.value}] {t.title} (优先级: {t.priority})) def main(): # 初始化世界 world WorldState() world.add_task(学习 Code as Worlds 概念, priority2) world.add_task(写一篇技术博客, priority1) executor Executor(world) steps [ 添加任务 阅读《智能体设计指南》, 完成学习 Code as Worlds 概念, 查看当前世界状态, 完成写一篇技术博客, ] for instruction in steps: print(f\n 用户指令: {instruction}) code plan_next_action(world, instruction) print(f 生成代码:\n{code}) result executor.run(code) if result[success]: print(f 执行成功输出: {result[outputs]}) else: print(f 执行失败: {result[error]}) print(\n最终世界状态:) world_dict world.to_dict() for t in world_dict[tasks]: print(f #{t[id]} [{t[status]}] {t[title]}) if __name__ __main__: main()4.6 运行效果与现象分析在终端执行cd agent-world-demo python main.py预期输出类似 初始世界状态 #1 [pending] 学习 Code as Worlds 概念 (优先级: 2) #2 [pending] 写一篇技术博客 (优先级: 1) 新增任务 ID: 3 任务 #1 已标记为完成 查看世界状态打印所有任务 任务 #2 已标记为完成 最终世界状态: #1 [done] 学习 Code as Worlds 概念 #2 [done] 写一篇技术博客 #3 [pending] 阅读《智能体设计指南》从这个示例中能直观看到“可执行世界表征”的闭环世界状态是结构化的对象智能体通过代码改变状态而状态变化又会影响下一次决策。如果真正接入 LLM只需要将plan_next_action内部的规则替换为将world_state.to_dict()与用户指令一起发送给模型要求模型返回可执行 Python 代码。然后继续用Executor执行并返回结果就构成了一个最简的 Code Agent。5. 理解 Code as Worlds 的工程意义5.1 从“推理型智能体”转向“执行型智能体”当前很多智能体平台强调“推理能力”但真实世界的任务最终需要落在执行上。代码执行的结果是可验证的任务完成就是完成失败就是失败不存在模棱两可。这使得智能体的可靠性评估成为可能。如果把世界表征设计成代码结构每一次动作都能进行单元测试、日志审计和状态回滚这是纯自然语言 Agent 很难做到的。5.2 Tool Calling 与代码生成的边界选择工程实践中智能体并不总是需要生成完整程序。很多场景下调用预定义工具更安全高效。于是我们需要区分两个层次操作方式优点缺点适用场景工具调用Function Calling安全可控参数受限灵活性不足固定业务操作如查订单、发消息生成代码执行表达能力强可处理复杂任务风险高需要沙盒数据处理、脚本生成、探索性分析生成代码后人工确认兼顾安全与灵活打断自动化流程生产环境变更、权限敏感操作领域特定 DSL受限但表达力强需要额外学习成本配置管理、规则引擎一个成熟的智能体系统应该同时支持这几个层次。简单操作走工具调用复杂任务自动生成代码高危操作要求人工审批。这也是 Claude Code、Dify 这类平台重点设计的功能。5.3 世界表征的可逆性与审计引入代码作为世界操作媒介后我们需要重点关注“可逆性”。建议在工程中做到每个会改变世界状态的函数都输出 before / after 快照。对可能修改数据的操作保留 undo 函数。涉及数据库操作时优先使用事务。敏感操作记录审计日志内容包括操作人、时间、执行代码、结果。这些要求在传统后端开发中已经是常识但在智能体开发中经常被忽略。很多智能体项目上线后出现“改错文件”、“误删数据”的严重事故根本原因就是没有把世界操作纳入代码审阅和回滚体系。6. 常见问题与排查思路开发 Code Agent 的过程中团队经常遇到以下几类问题。这里我把高频现象、原因和解决思路整理成表格方便对照排查。问题现象常见原因解决思路调用 API 返回 401 UnauthorizedAPI Key 未配置、过期或权限不足检查环境变量与密钥确认服务账号权限模型生成的代码语法错误上下文窗口不足导致截断或模型能力不够增加重试机制压缩上下文使用更强模型代码执行超时任务循环未终止或资源消耗过大为执行器设置超时时间限制 CPU 和内存生成的代码能运行但结果错误模型对世界状态理解有误或参数名写错将世界状态结构以 JSON 形式显式注入提示词沙盒执行权限不足容器未挂载必要卷或缺少系统依赖检查沙盒环境配置按最小权限逐步放行本地进程崩溃如 0xC0000005环境内存访问越界或依赖冲突检查依赖版本使用隔离容器运行上下文窗口中世界状态过大状态序列化没有裁剪或压缩只传入关键字段增加状态摘要层Agent 反复执行相同的错误操作缺少失败记忆或纠错机制将执行失败信息写回上下文增加反思步骤多智能体协作时状态不一致共享状态没有加锁或版本控制引入乐观锁、版本号或事件溯源机制生成代码尝试访问敏感系统提示词未定义边界缺少安全过滤器在提示词中声明禁止操作清单执行器做策略拦截这套排查思路适用于大多数 Code Agent 项目。核心原则是不要假设生成代码一次成功要为每步都加上验证和回退机制。7. 最佳实践与工程建议7.1 把世界状态“显式化”使用 Code as Worlds 思想时最重要的一点是让世界状态显式可见。不要让模型通过“猜”来理解系统而是主动把状态对象、数据结构、接口签名暴露给它。推荐做法定义状态 Schema并把 JSON 示例放入系统提示词。所有状态变更函数必须以统一前缀命名例如world_add_、world_update_、world_delete_。状态变更记录version或updated_at方便追踪版本。为复杂状态提供摘要函数避免上下文爆炸。7.2 安全边界先于功能开发智能体能够执行代码后安全风险会指数级上升。在项目初期就要确定安全边界禁止操作清单例如禁止删除生产数据库、禁止读取私钥文件、禁止连接未知外部主机。操作分级只读操作自动执行可写操作需要审批危险操作强制人工确认。资源限制为代码执行设置超时、内存限制、网络限制。审计日志完整记录智能体的代码生成、执行结果、用户反馈。合法授权和最小权限原则必须贯穿始终。不要为了一时的便利让智能体获得过大权限。7.3 提示词与代码结构分离有些团队习惯把大量上下文塞进 Prompt结果上下文越来越长效果却越来越差。更稳妥的做法是将“世界状态结构”放在程序代码中由工具调用注入。将“业务约束”放在系统提示词中。将“参考示例”放在少量 few-shot 中。将“领域知识”放在 RAG 数据库或外部文档中。这样模型看到的上下文更精炼决策质量更稳定。7.4 重视可观测性智能体执行过程的可观测性往往被低估。建议为每个智能体任务建立类似 Tracing 的日志任务 ID模型输入截断后模型输出代码执行结果世界状态变化 before / after用户反馈或人工干预记录有了这些数据你能在智能体行为失控时精准定位问题也能用失败数据微调模型或提示词。7.5 渐进式自动化许多智能体项目失败是因为团队试图一次性完成全自动闭环。更稳妥的策略是“渐进式自动化”第一步智能体只做分析和建议由人执行。第二步智能体生成代码人在沙盒环境运行。第三步智能体在测试环境自动运行结果由人复核。第四步智能体在生产环境运行低风险任务保留审批。第五步高风险任务也交由智能体自动执行但必须配备完备的回滚机制。在这个过程中智能体逐步获得对“可执行世界表征”的掌控团队也积累了足够多的运行数据和安全经验。7.6 关于主流工具的一点点提示当前社区里讨论较多的 Claude Code、Dify、Codex、Kimi Code 等工具本质上都在为用户构建“智能体发现并操作世界”的通道。这些工具版本迭代极快安装方式、API 参数、平台策略经常变化。建议在使用时遵循以下原则以官方文档为准不要轻信网络上的“一键安装脚本”。不要盲目执行从网上复制下来的未知命令尤其是涉及修改系统配置、安装二进制文件的命令。涉及 API Key 的配置务必通过环境变量或密钥管理服务注入不要硬编码进代码和配置文件。网络上的报错信息不一定是你的环境问题先复现、再排查、后处理。8. 从 Code as Worlds 到更复杂的智能体系统如果你理解了本文的示例和工程思路下一步可以沿着这些方向深入多智能体协作多个智能体共享同一个“世界状态数据库”通过事件消息协作。这时需要重点设计状态一致性和并发控制。长期记忆与学习智能体把过去执行的代码片段沉淀为“技能库”在面对类似任务时直接复用。这与“让智能体发现可执行世界表征”一脉相承。领域专用世界模型针对特定业务如工业控制、金融风控、电商运营构建专属状态对象和操作原语让 LLM 只生成符合领域约束的代码。世界模型评测建立仿真环境自动评测智能体对不同世界状态的感知、决策和执行质量。这是未来 Agent 工程的重要方向。回到最初的问题智能体到底在“理解”什么Code as Worlds 给出的答案是智能体理解的内容是一组可以被代码读写、执行和验证的世界状态与状态转换规则。代码越接近世界的真实结构智能体的行为就越可靠。当你在开发智能体时不妨先问自己几个问题我要操作的世界有哪些关键对象这些对象的状态如何变化哪些动作需要被记录和回滚如何让模型“看见”当前状态把这些想清楚再写代码智能体会变得稳健得多。希望这篇文章能给你一些启发也欢迎在实际项目中尝试“用代码构建世界”的做法对比一下与传统 Prompt 工程的差异。