乐于分享
好东西不私藏

智能体软件工程【第 3 讲】——计算范式演进:为什么 Code Mode 正在淘汰传统 Tool Calling?

智能体软件工程【第 3 讲】——计算范式演进:为什么 Code Mode 正在淘汰传统 Tool Calling?

【第 3 讲】计算范式演进:为什么 Code Mode 正在淘汰传统 Tool Calling?

NOTE

专栏导航👈 上一讲:【第 2 讲】智能体的“USB-C 革命”:彻底厘清 Tools、MCP 与 Skills 的分工👉 下一讲:【第 4 讲】认知与工作内存:智能体的“三级外脑”与上下文工程


一、 传统 Tool Calling 的系统性瓶颈

在过去的智能体开发中,最经典的交互模式莫过于 Function Calling / Tool Calling: 开发者把外部 API 转换成 JSON Schema,包含函数名称、参数类型与字段描述,在会话启动时全量注入大语言模型的系统上下文中。

这种模式在面对 3 ~ 5 个简单工具时工作良好。但当进入真实的复杂企业系统时,系统性瓶颈立刻显现:

瓶颈 1:百万 Token 的“接口定义爆炸”

假设要让智能体管理大型云基础设施(如 AWS 或 Cloudflare),完整的 API 规范包含数百个服务、上千个端点。仅仅是把所有端点的 JSON Schema 注入模型,就要消耗 超过 117 万个 Token

  • 后果:任何前沿大模型的上下文窗口在初始化阶段即被大量侵占,尚未执行具体业务便产生巨额计算开销与延迟。

瓶颈 2:“海量中间数据”造成的上下文过载与多轮往返延迟

考虑一个常见场景:“下载上周 5 场高管战略会议的音频转录文本,提取每位高管提到的产品改进建议,去重并汇总填入工单系统”。

  • 传统模式做法
    1. 调用 get_transcripts(),返回 10 万字的原始文本,全量回传并灌入模型上下文;
    2. 模型阅读后,调用 extract_action_items(),再次返回大段切片文本;
    3. 经历 5 ~ 6 次 HTTP 往返,模型上下文中充斥着大量口语冗余词,注意力被严重稀释,进而产生幻觉或关键信息遗漏。

二、 破局之道:代码执行模式(Code Mode)

2025–2026 年,Anthropic 与 Cloudflare 等团队全面引领了一场计算范式革命—— 代码模式(Code Mode)

IMPORTANT

核心计算哲学避免让大语言模型充当在多个 API 之间来回搬运海量原始文本的“数据中转工”;给模型配备一个受限隔离的安全沙盒,让其作为“脚本编写者”,在本地直接编写并执行确定性数据流过滤脚本!


三、 渐进式信息披露(Progressive Disclosure):1000 Token 精简覆盖全套 API

在 Code Mode 架构下,系统不再向模型全量暴露上千个工具的 Schema,而是 仅仅暴露两个精炼的核心元工具

  1. search_api(query: str)
    :用于按需检索外部 API 的类型定义与精简文档;
  2. execute_code(script: str)
    :在沙盒环境中执行模型生成的确定性自动化脚本。

2. 智能体的实际运转过程:

  1. 按需探索:智能体发现自己需要操作工单,于是调用 search_api("jira create issue"),仅检索出相关的 1 ~ 2 个函数类型定义(消耗 < 500 Token);
  2. 编写整合脚本:智能体在沙盒中编写包含数据过滤与条件判断的脚本:
    # 智能体自主生成的沙盒脚本transcripts = get_all_transcripts(since="2026-08-01")action_items = []for item in transcripts:# 本地确定性过滤,无需占用 LLM 推理算力if"建议"in item.text or"改进"in item.text:        action_items.append(clean_and_format(item))# 直接批量写入,不再把海量转录往返传回模型上下文jira_client.bulk_create_issues(action_items)print(f"成功创建 {len(action_items)} 个工件!")
  3. 返回精炼结果:沙盒执行脚本后,仅仅将 成功创建 5 个工件! 这一行确定性输出返回给模型。

原本需要消耗上百万 Token、历经多次 RPC 往返的长链路任务,被大幅度精简压缩至 仅约 1,000 Token,执行耗时与网络往返开销得到数量级的下降!

3. Codex 执行沙盒 Harness 的最小实现骨架

在工程底层,支撑 Code Mode 运转的是一个轻量级的 Codex 代码执行沙盒 Harness。它负责安全隔离、子进程调度与输出高信噪比提炼:

# Codex 最小代码沙盒 Harness (Execution Sandbox)import subprocessimport tempfilefrom dataclasses import dataclassfrom typing importOptional@dataclassclassSandboxResult:    stdout: str    stderr: str    exit_code: int    is_success: bool    truncated: boolclassCodexSandboxHarness:"""受限代码执行沙盒 Harness"""def__init__(self, timeout_sec: int = 30, max_output_bytes: int = 4096):self.timeout_sec = timeout_secself.max_output_bytes = max_output_bytesdefexecute_code(self, script_code: str) -> SandboxResult:"""在受限隔离环境中执行 Python 脚本并捕获高信噪比输出"""with tempfile.NamedTemporaryFile(mode="w", suffix=".py", delete=Trueas tmp:            tmp.write(script_code)            tmp.flush()try:# 隔离子进程执行 (生产环境使用 V8 Isolate 或 MicroVM / Docker 容器)                proc = subprocess.run(                    ["python3", tmp.name],                    capture_output=True,                    text=True,                    timeout=self.timeout_sec,                )                stdout = proc.stdout[:self.max_output_bytes]                is_truncated = len(proc.stdout) > self.max_output_bytesreturn SandboxResult(                    stdout=stdout,                    stderr=proc.stderr[:self.max_output_bytes],                    exit_code=proc.returncode,                    is_success=(proc.returncode == 0),                    truncated=is_truncated,                )except subprocess.TimeoutExpired:return SandboxResult(                    stdout="",                    stderr=f"执行超时熔断: 超过 {self.timeout_sec} 秒限制",                    exit_code=-1,                    is_success=False,                    truncated=False,                )

该沙盒 Harness 充当了模型与物理宿主间的防护边界:它只允许结构化代码进入,且在输出超过设定阈值时执行滑动截断,从源头上杜绝了海量原始终端日志导致上下文窗口过载与注意力稀释。


四、 经验沉淀与“技能飞轮”

Code Mode 不仅节约了算力和带宽,更赋予了智能体一种自我强化的能力—— 自主沉淀可复用的能力资产

一旦智能体成功编写并验证了一段处理特定业务的脚本,Harness 基础设施就可以将其持久化固化为一个本地 Skill 模块。未来面对同类需求时,系统能够以确定性的方式直接执行,彻底规避了大模型重复推理的高昂成本与潜在的随机性风险。


五、 本讲小结与核心思考题

TIP

核心结论“静态 Tool Calling 是试图把整个工具箱硬塞进模型的上下文记忆中;而 Code Mode 是为模型配备执行沙盒,让其在工具库中按需检索并自主组装确定性流水线。”

💡 留给你的思考题:

当智能体在长达数天甚至数周的项目中持续运行时,除了即时的代码执行能力,它如何持久化历史异常与修复经验?面对海量业务背景,我们又该如何设计其内部的多层记忆系统与工作内存?


NOTE

下一讲指引为什么传统的向量检索(RAG)经常导致断章取义?智能体的情节记忆(Episodic Memory)与状态检查点如何实现长周期任务的自愈?请看:👉 【第 4 讲】认知与工作内存:智能体的“三级外脑”与上下文工程