1. 先把“执行”这一层想透智能体凭什么能动手1.1 从 Function Calling 到 Tool Use一次调用的完整生命周期真正把 LLM 从“对话机器人”变成“智能体”的分水岭不是模型能写多长的作文而是它能不能在对话之外真正做点事。过去一年我做了好几个智能体项目最深的体感是能不能“动手”取决于你给模型接上了多少只“手”以及这些“手”够不够稳。所谓执行层简单说就是让大模型输出一段结构化的工具调用请求然后由你的程序去真实执行。先拆开看一下“一次函数调用”到底发生了什么。你用 Function Calling 给模型声明了一批工具比如一个delete_file(path)工具描述里写清楚参数名、类型、是否必填。模型在推理时如果判断需要删除文件它不会自己去删而是返回一段特殊格式的 JSON{name: delete_file, arguments: {path: /tmp/old.log}}。你的运行时拿到这个 JSON找到对应的 Python 函数填充参数真正执行拿到返回值再把返回值拼进下一轮对话的上下文里交给模型。这里最容易翻车的环节恰恰是看起来最不起眼的“对话内容”。我在实际项目里反复踩过同一个坑工具返回结果很长尤其是执行日志、目录列表、数据库查询结果一不小心就是几千个 token。你把全文塞回上下文模型确实能“看到”结果但下一轮它的注意力会被无关输出稀释而且成本直线上升。所以执行层有个约定俗成的处理对返回结果做截断、摘要或结构化压缩。我个人通常把返回结果限制在 3000 字符以内关键字段单独提取日志只保留尾部几百行。别小看这个细节直接决定你的智能体在多轮复杂任务里能不能保持清醒。1.2 让“动手”可控执行上下文、超时与并行策略执行上下文这个词很多做后端的朋友不会陌生但在智能体场景里它有另一层含义一次任务执行从开始到结束所有工具调用之间到底共享什么状态。比如一个“批量处理报表”的任务第一步是读取文件列表第二步是逐个处理第三步汇总结果。第二步的每一次处理是否依赖第一步读到的列表是否需要把中间结果存到某个临时变量里这就是执行上下文要回答的问题。我比较推荐的方案是“上下文显式传递”。不要让工具函数自己偷偷存全局变量而是把中间结果作为参数传进下一步工具。这样虽然写起来啰嗦一点但每一步都可以单独重放、单独测试出了问题也知道是哪一步的数据不对。配合“超时控制”一起做效果更好。每个工具调用必须有超时上限比如 Python 代码执行器 30 秒、外部 HTTP 请求 15 秒、文件操作 5 秒。没有超时的执行层就像没有保险丝的电路一个死循环就能让整个智能体卡死。再说并行。现在的模型接口普遍支持一次返回多个工具调用比如同时给三个不同目录做备份。这确实能大幅提升效率但并行执行有个隐含要求工具之间不能互相依赖。我处理的办法是先画一个简单依赖图两个工具如果读写同一份文件或者一个的输出会变成另一个的输入坚决不并行。宁可顺序执行慢一点也不让数据竞争产生诡异 bug。顺序执行和并行执行不是二选一在实际链路里往往是混合编排的这个我放到后面接管部分详细聊。2. 接管把“决定权”交给智能体但保留刹车的权力2.1 智能体循环与任务编排从“单次调用”到“循环作战”单次 Function Calling 能处理的场景很有限真实任务通常要模型经过“观察—思考—行动—再观察”的多轮循环才能完成。这就是大家经常听到的 Agent Loop。我常用一个很朴素的描述智能体是一个自带循环的体力劳动者它每轮想一步、做一步做完看结果再想下一步直到主动说“任务完成”。这个循环看起来简单真正落地时有两个地方最考验设计。第一循环什么时候停。不能只依赖模型说“完成”因为模型可能误判。我的经验是同时设三个停止条件模型主动结束、达到最大轮数一般 8 到 10 轮、某个关键校验函数返回成功。三个条件任何一个满足就强制终止。第二每一步之间怎么衔接。这里我用了一个非常通用的“三明治”结构任务目标放在系统提示词最前面每轮对话先让模型输出一句简短的“行动理由”再输出工具调用。这样每一轮都在“解释自己为什么这么做”等到需要排查问题时这些理由就是现成的执行日志。接管这个词听起来有点吓人实际上把控制流交给智能体并没那么恐怖。关键在于你要把“决策权”和“操作权”分开。决策权指模型可以决定接下来调哪个工具操作权指真正执行命令的能力。我的习惯是决策权可以大胆给操作权必须留后手。比如模型可以“决定”删除某个文件但删除前必须经过审批钩子检查路径是否在允许范围内。这样即使模型判断错了损失也是可控的。2.2 自主度分级全自动、半自动、人工审批的模式怎么定做智能体产品时最常被问到的一个问题是“你能不能全自动不用我管”我的回答通常是能但你大概率不敢。不同场景对自主度的要求差异很大所以比较合理的做法是把“接管程度”做成一个可配置的档位而不是一刀切。我把自主度分成三档。第一档是“建议模式”模型只输出工具调用建议不真正执行由人确认后点击执行。这个模式适合高风险操作比如生产环境删除数据、发对外邮件、支付操作。第二档是“半自动模式”默认执行但遇到规则里的高风险工具或异常条件时暂停请求人工确认。大多数内部效率工具用这个档位最合适——比如自动整理代码仓库、自动处理日志都不需要每个步骤都问人但在“批量删除”这种动作前停一下。第三档是“全自动模式”模型完全自主执行所有工具只最终汇报结果。适合完全隔离的沙箱环境比如代码生成、轻量数据分析、自动化测试跑批。我在实际项目中是这样落地的每个工具声明一个risk_level字段低风险默认放行中风险记录日志并异步通知高风险强制等待人工确认。审批消息通过 Webhook 推给值班人员附带执行前快照和执行后的预估影响。这样既保留了自动化的效率又不会对不可控的操作彻底失明。如果产品对响应速度要求高我建议把审批做成“超时自动降级”——5 分钟没回应就自动转成“暂停不执行”而不是默认放行。宁可任务等待也不能在无人监管时执行危险操作。3. 隔离没有隔离的执行就是给自己挖坑3.1 三种隔离维度容器、网络、权限分别解决什么问题我对“智能体自己动手”这件事的安全底线一直是很固执的任何真实世界的操作都必须发生在隔离环境里。这里的隔离不是一种技术而是三件套容器隔离、网络隔离、权限隔离。它们解决的完全是不同层面的问题缺一个都可能出事。容器隔离解决的是“进程跑飞了怎么办”。智能体执行一段代码可能是生成的 Python 脚本也可能是调用的命令行工具。不隔离的话一个rm -rf就能把你宿主机上的文件清空一个死循环就能烧满 CPU。用 Docker 容器跑执行任务相当于给智能体一个独立的文件系统和进程空间它在里面再怎么折腾也只是折腾容器里的那层“虚拟环境”。容器资源隔离尤其重要我通常会限制 CPU 核数、内存上限、磁盘配额和最大运行时长避免单个任务把整台机器拖垮。网络隔离解决的是“数据出不去、外部进不来”的问题。智能体需要访问外网资源比如下载依赖、调用远程 API但绝对不能让它无限制访问网络。我的做法是默认禁止所有出站流量只按白名单开放特定域名和端口。如果需要访问内网服务就走专门的代理通道。反向方向也要设防不要让你的执行容器暴露不必要的端口防止外部恶意流量探进来。网络域隔离这件事做过运维的朋友都熟但放在智能体场景里经常被忽略——很多人觉得“反正是我自己的代码”结果给组织内网留了个后门。权限隔离解决的是“即使出了事损失也有限”的问题。容器内的进程应该以非 root 用户运行容器的挂载目录只读为主宿主机目录只挂载任务必需的那一小块。更进一步智能体使用的 API 密钥、数据库密码、私钥都应该存放在独立密钥管理系统里运行时通过环境变量注入而不是写在代码里。这样即使容器被攻破或者智能体逻辑错乱攻击者拿到的也只是任务范围内的那一丁点权限。三件套叠加起来才是完整的信任边界。3.2 最小权限沙箱的落地配置Docker 示例下面给出一套可以抄作业的“最小权限沙箱”配置专门用于跑智能体的代码执行器。这套方案我跑过几个月稳定性不错改动也少。# 使用精简基础镜像减少攻击面 FROM python:3.12-slim # 创建一个非 root 用户 RUN groupadd -r runner useradd -r -g runner runner # 只安装任务必需的依赖不要装全套开发工具 COPY requirements.txt /tmp/requirements.txt RUN pip install --no-cache-dir -r /tmp/requirements.txt # 工作目录放在独立的可写卷其他路径只读 RUN mkdir -p /workspace chown runner:runner /workspace WORKDIR /workspace # 切换到非 root 用户 USER runner # 执行入口 CMD [python, /app/runner.py]启动容器时的关键参数比 Dockerfile 本身更重要docker run --rm \ --name agent-executor \ --cpus 1 \ --memory 512m \ --pids-limit 100 \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size64m \ --cap-drop ALL \ --security-opt no-new-privileges \ --network none \ -v /data/task-input:/workspace:ro \ -v /data/task-output:/workspace/output:rw \ agent-executor逐条解释一下关键参数--memory 512m限制最大内存防内存溢出--read-only让根文件系统只读防篡改系统文件--tmpfs /tmp给程序一个可写的临时目录但不允许执行二进制且容量只有 64m--cap-drop ALL丢掉所有 Linux 权限能力容器里的进程什么都做不了特权操作--network none直接断网如果需要访问白名单域名我会再单独起一个代理容器通过内部网络做转发。输入目录以只读方式挂载输出目录单独隔离。这套配置跑智能体代码执行器我认认真真测过十几种“搞破坏”的场景效果稳。不过要泼一盆冷水容器隔离不是万无一失的。内核级漏洞、错误挂载、容器 API 暴露都可能造成逃逸。我的态度是隔离是减损手段不是免死金牌。更重要的事情是尽量别让智能体拿到“能够造成严重后果的工具”。能通过读取操作完成的就不要给写权限能通过临时环境完成的就不要给生产环境凭证。把工具面收到最小隔离压力自然会小很多。4. 实操记录搭一套“执行—接管—隔离”完整链路4.1 一个最小可用的智能体执行后端讲了这么多抽象概念我直接给出一个我实际用过的最小执行后端骨架。它做的事非常简单接住模型传来的工具调用请求校验参数执行对应函数返回结构化结果。代码不长但包含了超时、权限校验、结果截断三个关键处理。import json import time import traceback from enum import Enum from typing import Callable, Any class RiskLevel(Enum): LOW low MEDIUM medium HIGH high class Tool: def __init__(self, name: str, description: str, parameters: dict, risk: RiskLevel, func: Callable[..., Any]): self.name name self.description description self.parameters parameters # JSON Schema 格式 self.risk risk self.func func def to_schema(self) - dict: return { type: function, function: { name: self.name, description: self.description, parameters: self.parameters } } class Executor: def __init__(self, timeout: float 10.0, max_result_len: int 2000): self.tools: dict[str, Tool] {} self.timeout timeout self.max_result_len max_result_len def register_tool(self, tool: Tool): # 工具名必须唯一和模型输出严格对齐 self.tools[tool.name] tool def execute(self, tool_call: dict) - dict: name tool_call.get(name) arguments json.loads(tool_call.get(arguments) or {}) tool self.tools.get(name) if not tool: return {ok: False, error: ftool {name} not found} # 高风险操作留审批钩子默认拒绝 if tool.risk RiskLevel.HIGH: if not self.require_approval(tool.name, arguments): return {ok: False, error: blocked by approval hook} result {ok: False, error: unknown error} try: start time.time() raw tool.func(**arguments) elapsed time.time() - start if elapsed self.timeout: result {ok: False, error: ftimeout after {self.timeout}s} else: text json.dumps(raw, ensure_asciiFalse, defaultstr) if len(text) self.max_result_len: text text[: self.max_result_len] ...[truncated] result {ok: True, data: json.loads(text)} except Exception: result {ok: False, error: traceback.format_exc()[-1500:]} return result def require_approval(self, name: str, arguments: dict) - bool: # 实际环境里这里会接入审批队列推送 Webhook print(f[APPROVAL REQUIRED] {name}({arguments}) - granting by default in demo) return True这段骨架看起来简单但逻辑闭环很完整工具注册、参数校验、超时保护、权限钩子、异常捕获、结果截断全都有。真实项目里我会再补两块一个是审计日志每次执行都要记录工具名、参数摘要、执行人标识、耗时和结果状态另一个是“重复保护”防止智能体在循环里反复执行同一个工具导致副作用累积。比如同步数据这种任务被调用了三次前两次的结果还在处理中就必须拒绝第三次。4.2 任务编排与配置示例如何把工具串成工作流有了执行后端下一步是把多个工具串成一个工作流。我的做法是定义一张任务编排表用配置驱动的方式告诉系统“哪些步骤是顺序的、哪些可以并行”。以下是一个“自动化代码仓库整理”任务的示例配置。task: 代码仓库整理 steps: - id: scan tool: list_files args: root: /workspace/repo policy: sequential - id: classify tool: classify_file args: files: ${scan.output} policy: parallel depends_on: scan - id: duplicate_report tool: find_duplicates args: files: ${scan.output} policy: sequential depends_on: scan - id: cleanup tool: move_to_trash args: files: ${classify.output.obsolete} policy: approval_required depends_on: classify, duplicate_report这个配置的核心逻辑是scan先执行classify和duplicate_report都只依赖scan所以可以并行最后cleanup依赖前两个结果并且是“高风险操作”必须走审批。我把policy字段设计为sequential、parallel、approval_required三种本质上就是对第二节“自主度分档”的工程表达。执行引擎在跑这个配置时会把scan的输出作为上下文变量传给classify实现执行上下文在步骤之间的显式传递。每一步的返回值都会追加进 Trace 上下文方便链路追踪。生产版本我还加了一个“自愈”逻辑如果某个步骤失败引擎先判断依赖是否满足重试条件满足就自动重试一次不满足就挂起并通知值班人员。注意重试只适用于“幂等”的读取操作对于写操作宁可失败也不能盲目重试这是用事故换来的认知。5. 真实踩坑现场这些问题我调试过一整夜5.1 四个典型故障的发生与修复第一个印象深刻的坑是“工具参数类型错位”。模型返回的arguments里数字可能变成字符串数组可能变成逗号分隔的文本。我用json.loads解析后直接**arguments传给 Python 函数结果因为类型不匹配抛出异常而且异常信息非常隐晦。后来我加了显式的参数类型校验器每个字段按 JSON Schema 校验一遍再执行。比如要求int类型就用int(value)强转转不动就直接拒绝调用并在错误信息里提示模型“参数类型错误请重新生成”。这一步把执行失败率砍掉了 40% 左右。第二个坑是“超时设置得太宽松”。一开始我把超时统一设成 120 秒想着给模型充足时间。结果遇到一个循环调用附近文件的 bug一个任务里反复执行了十几次工具调用每次都卡到超时整个流程拖了一小时也没跑完。后来我把超时分成两段单次工具调用最多 15 秒整个任务最多 30 秒。任务超时后强制终止循环并且把已有产出保存下来这样至少不会白跑。执行超时解决的不仅是性能问题更是帮智能体“体面地退出”。第三个坑是“容器内依赖缺失产生虚假失败”。智能体生成一个 Python 脚本需要pandas但沙箱镜像里没装执行直接报ModuleNotFoundError模型看到错误后居然尝试“安装依赖”——调用pip install折腾几轮还是失败。后来我在工具描述里明确写明“沙箱已预装依赖清单”并在执行器里拦截所有安装类命令直接返回“环境不支持安装”。要装依赖只能走镜像更新流程提交新需求后统一打新镜像。这样既稳定又安全。第四个坑是“成本失控”。全自动模式的智能体一旦跑起来如果任务定义得不够收敛它会像好奇的小孩一样东摸西碰每轮调用都在烧 token。我曾经一个晚上跑出 200 多美元账单而且任务还没完成。从那以后我在执行循环里加了两道保险每轮调用前检查已用 token 是否超过预算任务开始前让模型先输出“我的执行计划”预估最多多少轮、要调用哪些工具。如果计划看起来像无底洞系统直接拒绝启动。成本不是事后看账单而是要在执行前就算清楚。5.2 执行链路健康检查清单下面这张清单是我每次上线一个智能体执行模块之前都要逐项过一遍的整理成速查表分享给读者。检查项问题边界处理建议预警级别工具参数校验模型返回的参数类型、字段缺失引入 JSON Schema 校验失败则提示模型重生成高超时控制单次调用、整个循环均可能卡死单次 15s任务 30s超时自动终止高结果截断工具返回过长污染上下文限制 2000~3000 字符保留关键字段中幂等性重复执行写操作导致副作用累积写操作加防重标记重试前确认状态高权限审批高风险工具被自动执行按风险等级分级高风险强制审批高成本预算循环调用导致 token 消耗失控执行前预估轮数每轮检查预算中沙箱依赖运行环境与预期不符镜像固定依赖清单禁止运行时安装中网络策略容器可访问未授权域名默认断网白名单代理内网服务单独通道高这张表不要当成摆设每一次事故复盘都能从里面找到对应项。特别提醒一句检查清单要随着运行情况持续更新。我第一次写的时候没有“幂等性”这一条后来吃了大亏才补上。智能体的执行链路迭代很快今天没踩过的坑明天可能就在线上等着你。6. 我个人现在做智能体执行器的一个习惯最后分享一个我在多次“现场翻车”之后沉淀下来的习惯任何智能体执行链路必须保留完整的中间状态快照。我指的是每次工具调用的输入输出、每轮模型回复的原始内容、任务执行的全局上下文都落盘保存。这个习惯在排查问题时的价值超乎想象——智能体抛出一个莫名其妙的结果你如果没有快照只能靠猜有了快照你可以回放整个决策过程看到底是模型理解偏了、工具返回脏数据还是编排逻辑写错了。具体落地上我会在任务开始时创建一个独立目录命名为trace_{task_id}里面按序号保存01_model_reply.json、02_tool_call.json、03_tool_result.txt这样的小文件。磁盘开销不大但排查效率至少翻一倍。另外这些快照本身就是很宝贵的调试语料当模型表现变差时你可以从快照里提取出“错误示范”做成回归测试集防止同一个坑反复踩。智能体“自己动手”才刚起步执行、接管、隔离这三个词也远没有标准答案。但只要你把执行层当成一个严肃的工程系统去设计把控制权分级做清晰把隔离当成默认动作而不是事后补救这条路走起来会稳很多。我还在持续调整这套方案欢迎有同样实践的同行多交流。