Airflow里跑AI代理，沙箱只是子进程，敢用吗？

Apache Airflow 发布了 AI Provider 1.0，把代理编排的基础能力塞进了一个已经在成千上万条生产数据管道里跑的调度引擎。它不是一个新代理框架，而是一组 DAG 任务：让你在现有 Airflow 工作流里跑大模型代理，带上沙箱、人工审批和能区分"模型挂了"还是"工具挂了"的重试逻辑。

这个 Provider 装在 Airflow 2.11 及以上版本，还留在 Airflow 2 的团队不用升级整个平台就能用上代理。核心原语有三个：代理任务、沙箱化代码执行、以及接入 XCom 系统传递上下文的人工审批门。

它到底往 DAG 里加了什么

Common AI Provider（apache-airflow-providers-common-ai）给 DAG 补了三样能力：

• 代理任务：在一个 DAG 步骤里跑带工具调用的大模型循环
• 沙箱执行：把代理生成的代码和 Airflow 进程隔开
• 人工审批门（需 Airflow 3.3+）：暂停代理执行，等人批准某次工具调用

代理任务本质是一个在循环里干活的模型：调用 DAG 作者允许的工具、读结果、决定下一步，直到给出答案。Provider 把这个循环包进 TaskFlow API，所以它表现得和普通 DAG 任务一样，有重试、有日志、能通过 XCom 传数据。模型侧通过一个叫 pydanticai 的统一连接类型支持 OpenAI、Anthropic、Google 和 Bedrock，模型和 API Key 配在 Airflow 连接里，任务运行时读取。

沙箱的边界，比你想的窄

传统 Airflow 任务跑一次函数就完事，代理任务跑的是循环：模型拿到提示词和可用工具，调用工具（SQL 查询、API 请求、代码执行），结果回流给模型，模型再决定继续调工具还是收尾，直到返回最终结果或撞上重试条件。最终答案通过 XCom 交给下游任务。

代理写代码时，Provider 把它丢进沙箱而不是 Airflow worker 进程，目的是挡住几件事：碰 Airflow 的凭据和连接、改 DAG 状态或任务元数据、读沙箱目录之外的文件、访问内部服务的网络调用（除非显式放行）。

关键点在这里：沙箱不用容器也不用虚拟机，就是一个限制了导入和文件系统访问的 Python 子进程。开销低，代价是你得信任这套沙箱实现真能守住边界。要更强的隔离，得把代理任务包进 KubernetesPodOperator 之类的东西里。

人工审批门在 Airflow 3.3 及以上可用。代理想发 Slack、发邮件、跑写查询时，可以把工具标记为需要审批，任务随即暂停并生成审批请求，人在 Airflow UI 里看请求、批或拒，代理任务再继续。审批请求里带着工具名和参数、模型调用该工具的理由、循环里此前工具调用的上下文、以及代理当前计划的状​​态。拒绝则任务失败并按配置决定是否重试，批准则工具执行、结果回流给模型。审批请求和审批决定都是 XCom 值，下游任务读得到。

重试：模型超时和 SQL 写错不是一回事

Airflow 本来就会自动重试失败任务，但代理任务需要更聪明的判断：模型超时是暂时性的，一条非法 SQL 不是。Provider 给了两种重试模式：

• 自动重试：把所有失败都当暂时性故障，模型超时、工具调用失败、沙箱崩溃一律重跑整个代理任务。适合不稳定的 API 或限流，但遇到持续性错误就是白烧 token。
• 模型决定重试：工具调用失败时错误信息回流给模型，由模型决定换参数重试、换个工具、把错误返回给 DAG 作者，还是先请求人工审批。省 token，但多了一层延迟。

重试模式按代理任务单独配置，默认是带最大重试次数的自动重试。

可观测性方面，每个代理任务暴露这些指标：总 token 用量（提示词加补全）、工具调用次数、单次工具调用延迟、沙箱执行时间、审批等待时间。这些指标进 Airflow 现有的观测栈，可以走 REST API 查、导出到 Prometheus、或在任务日志里看。每次工具调用的参数和结果也会记日志，包括模型推理过程（如果模型暴露的话）、参数、结果或错误、循环每一步的耗时。token 数从模型 API 响应里读，模型不暴露就用分词器估算。

什么时候该用，什么时候别用

Airflow 自带调度开销。代理工作流对延迟敏感（亚秒级响应）就不该用它；按计划跑、或者作为更大数据管道的一环，才合适。沙箱隔离弱于容器和虚拟机，面对不可信代码或合规要求，得套 KubernetesPodOperator 或另起集群。人工审批门适合高风险动作，但会增加延迟，全自动流程就关掉它。

几个已知失败模式：模型调用默认超时 60 秒，超时任务失败并重试，可在任务配置里调大；工具参数非法时，自动重试模式重跑整个任务，模型决定模式则把错误交回模型；沙箱崩溃后重试不保留状态，代理从头开始；人工审批默认 1 小时超时，超时任务失败，可按任务配置；token 用量超限时模型 API 报错，而 Provider 不跨重试累计 token，得自己另外盯。

兼容性上有个坑：Provider 能装在 Airflow 2.11，但人工审批门要 3.3+，模型决定重试和沙箱执行在 2.11+ 可用。在 2.11 上，导入路径要从 airflow.decorators 换成 airflow.operators.python，agent_task 装饰器本身不变。

结论很直接：已经在跑 Airflow、想把代理任务塞进现有 DAG、需要人工审批门、想复用 Airflow 的重试与凭据管理，就用它；延迟敏感、需要强隔离、本来就没跑 Airflow、或者代理工作流完全独立于数据管道，就别用。它不是 LangGraph 或 CrewAI 这类独立代理框架的替代品，填的是"在现有工作流编排里跑代理"这个空档。