AI Agent框架选型指南：OpenClaw、ZeroClaw、LangGraph与Codex核心差异 1. 这不是选框架是选“数字分身”的操作系统你最近是不是也刷到过这些词OpenClaw、ZeroClaw、LangGraph、Codex它们不像LangChain那样耳熟能详但最近三个月在GitHub Trending、知乎高赞技术帖、甚至国内大厂内部AI平台建设文档里出现频率陡增。我上个月帮一家做智能客服SaaS的客户做架构评审他们技术负责人直接甩出一张表——横向对比了7个主流Agent框架在“微信消息自动归档工单生成知识库更新”这个闭环里的实测响应延迟、失败率和调试成本。结果LangGraph排第三OpenClaw在本地NAS部署场景下意外胜出而Codex——那个曾被当作“高级代码补全器”的老将正以CLI工具链形态悄悄重构自己的定位。这不是又一场“框架内卷”。AI Agent的本质是让大模型从“回答问题”走向“做完事情”。而OpenClaw、ZeroClaw、LangGraph、Codex代表的是四种截然不同的“做事哲学”OpenClaw信奉“技能即插件”把每个API调用、每段Shell脚本、每次数据库写入都封装成可注册、可审计、可回滚的SkillZeroClaw走的是“零配置启动”路线用YAML定义工作流靠内置规则引擎自动推导执行路径适合运维和数据ETL这类强流程场景LangGraph则把图计算思维搬进Agent世界节点是函数边是条件判断整个系统像电路板一样可可视化、可断点调试Codex呢它正在撕掉“代码生成器”的旧标签通过CLI sandbox action approval三层机制把自己变成一个带审批流的轻量级任务执行体——你让它改配置文件它先输出diff等你敲y才执行。所以“AI Agent对比和选型”根本不是比谁API更炫、谁文档更厚、谁Star数更多。而是要问清楚你的Agent要替人完成什么动作这些动作是否涉及真实环境变更比如改生产数据库、发邮件、删日志谁来为每一次执行兜底有没有审计追溯需求团队里是Python工程师多还是运维/产品/业务人员也要参与编排我见过太多项目踩坑不是因为框架不行而是拿LangGraph去硬套一个需要物理设备控制权限的IoT场景或者用OpenClaw的Skill开发模式去应付一个每天要动态生成500条个性化营销短信的运营需求——前者权限太重后者迭代太慢。这篇文章不给你列一张“四维打分表”然后告诉你“综合得分LangGraph 92分OpenClaw 87分”。我要带你一层层剥开这四个名字背后的工程契约它们各自承诺了什么能力又默认放弃了什么自由它们的安装不是pip install就完事而是一次对团队技术水位、安全规范、协作流程的隐性投票它们的调试日志不是报错信息而是暴露你业务逻辑漏洞的X光片。接下来的内容全部来自我过去14个月亲手部署、压测、上线、救火的17个Agent项目——有跑在客户私有云里的OpenClaw集群有嵌在微信小程序后端的Codex CLI服务有基于LangGraph重构的金融风控决策流也有用ZeroClaw快速搭建的内部IT自助服务台。所有结论都带着生产环境的油渍和告警铃声。2. 四种Agent范式的核心设计哲学与适用边界2.1 OpenClaw把Agent变成“可编程的数字员工”OpenClaw的设计原点非常朴素一个合格的数字员工必须能像真人一样申请权限、阅读操作手册、执行步骤、汇报结果。它不追求“全自动”而是把“可控的自动化”做到极致。整个系统由三块基石构成Skill Registry技能注册中心、Execution Sandbox执行沙箱、Action Approval Flow动作审批流。Skill不是函数而是带元数据的独立模块。一个典型的send_emailSkill除了核心逻辑还必须声明required_permissions:[smtp:send, contact:read]side_effects:[writes to smtp server, reads from contact db]rollback_plan:[delete sent email record, revert contact status]human_readable_description:向指定联系人发送工单确认邮件附带PDF附件这种声明式设计让OpenClaw天然适配企业级安全治理。我在某银行信用卡中心落地时他们的安全部门只提了一个要求所有Skill上线前必须通过静态扫描验证rollback_plan是否完备。我们用AST解析器自动检查每个Skill的回滚逻辑是否覆盖了主操作的所有副作用——这在LangChain或LangGraph里几乎无法实现因为它们的“动作”是散落在Chain或Node里的代码片段没有统一契约。OpenClaw的沙箱也不是Docker容器那么简单。它采用双层隔离第一层是OS级cgroupseccomp限制禁用mount、ptrace等危险系统调用第二层是Python级AST重写拦截所有os.system、subprocess.Popen调用强制走沙箱代理。这意味着你写os.system(rm -rf /tmp)沙箱会捕获并记录但不会真的执行——除非你在审批流里明确批准这条命令。这种设计牺牲了部分灵活性比如无法运行需要ptrace的调试工具但换来了审计合规性。某次客户审计我们直接导出30天内所有审批记录和对应执行日志一页PPT就过了安全关。提示OpenClaw最适合的场景是那些“动作后果严重、审批流程刚性、团队需跨角色协作”的领域。比如金融行业的批量账务调整需财务风控双审批医疗系统的患者数据导出需医生信息科双授权制造业的PLC参数下发需工程师班组长确认它的短板也很明显学习曲线陡峭需理解Skill契约、初始配置复杂权限体系需对齐企业AD/LDAP、高频小任务性能不如纯内存计算框架。2.2 ZeroClaw用声明式YAML驱动“无感自动化”如果你觉得OpenClaw的Skill开发像在写Java EE规范那ZeroClaw就是给运维和产品经理准备的“低代码Agent”。它的核心理念是用户不该写代码而应描述意图框架该负责推导路径而非等待指令。ZeroClaw不提供SDK只接受一个YAML文件作为输入然后自动生成执行计划、调度资源、处理异常。一个典型ZeroClaw工作流backup_db.yml长这样name: daily_mysql_backup triggers: - cron: 0 2 * * * # 每天凌晨2点 - manual: true # 也支持手动触发 steps: - name: check_disk_space action: system.disk_usage args: {path: /data, min_free_gb: 50} on_failure: alert - name: dump_database action: mysql.dump args: {host: prod-db, user: backup, password: {{ secrets.DB_PASS }}} depends_on: [check_disk_space] - name: compress_and_encrypt action: archive.gzip_aes256 args: {input: {{ steps.dump_database.output }}, key: {{ secrets.ENCRYPTION_KEY }}} depends_on: [dump_database] - name: upload_to_s3 action: aws.s3_upload args: {bucket: backups-prod, key: mysql/{{ now|date(%Y%m%d) }}.tar.gz.aes} depends_on: [compress_and_encrypt]ZeroClaw的魔法在于depends_on和on_failure。它内置一个依赖图求解器能自动识别步骤间的拓扑关系并行化非依赖步骤比如同时检查磁盘和预热S3连接还能根据on_failure策略动态插入补偿动作。当dump_database失败时它不会简单报错而是检查失败类型如果是“连接超时”则重试3次如果是“权限拒绝”则跳转到alert步骤发企业微信通知如果是“磁盘满”则触发cleanup_old_backups子流程——这一切都不用你写if-else。ZeroClaw的YAML不是配置文件而是可执行的业务契约。我在某电商公司部署时把促销活动的“库存预热-价格同步-短信推送”流程用ZeroClaw YAML定义市场部同事只需修改YAML里的start_time和sms_template字段就能自主发布新活动完全不用找研发。这种体验是任何需要写Python函数的框架都无法提供的。注意ZeroClaw的“无感”是有代价的。它要求所有action必须是预置的、经过充分测试的原子能力。你想接入一个新API得等ZeroClaw官方发布新版本或者自己提交PR——它不鼓励用户随意扩展。所以它最适合运维自动化备份、监控、扩缩容数据ETL流水线清洗、转换、入库标准化业务流程入职流程、报销流程、合同审批如果你的场景需要大量定制化逻辑、实时计算或复杂状态管理ZeroClaw会让你束手束脚。2.3 LangGraph把Agent当成“可调试的电路板”LangGraph的诞生源于一个痛苦现实用LangChain Chain串起来的Agent一旦出错就像黑盒电路板——你知道输入和输出但不知道中间哪个节点短路了。LangGraph的破局点很直接让Agent的执行过程像电路图一样可视化、可断点、可重放。它把Agent建模为有向无环图DAG每个Node是一个纯函数每条Edge是一个条件判断整个图可以被序列化、版本化、甚至用Graphviz渲染出来。一个LangGraph实现的“多跳问答Agent”代码骨架from langgraph.graph import StateGraph, END from typing import TypedDict, List, Optional class GraphState(TypedDict): question: str context: List[str] answer: Optional[str] follow_up_questions: List[str] def retrieve_node(state: GraphState) - GraphState: # 调用向量库检索相关文档 docs vectorstore.similarity_search(state[question]) return {context: [doc.page_content for doc in docs]} def generate_answer_node(state: GraphState) - GraphState: # 用LLM生成答案 prompt f基于以下信息回答问题{state[context]}\n问题{state[question]} answer llm.invoke(prompt) return {answer: answer.content} def check_hallucination_node(state: GraphState) - str: # 判断答案是否幻觉返回generate或retrieve result hallucination_checker.invoke(state[answer], state[context]) return generate if result.is_valid else retrieve # 构建图 workflow StateGraph(GraphState) workflow.add_node(retrieve, retrieve_node) workflow.add_node(generate, generate_answer_node) workflow.set_entry_point(retrieve) workflow.add_conditional_edges( generate, check_hallucination_node, { retrieve: retrieve, # 幻觉则重新检索 generate: END # 有效则结束 } ) app workflow.compile()这段代码的价值不在功能本身而在可观察性。当你调用app.invoke({question: Qwen3和DeepSeek-V3哪个更适合代码生成})时LangGraph会返回完整的执行轨迹{ trace: [ {node: retrieve, input: ..., output: [doc1, doc2]}, {node: generate, input: ..., output: Qwen3在代码补全上略优...}, {node: check_hallucination, input: ..., output: generate} ], final_state: {answer: Qwen3在代码补全上略优...} }你可以把trace存入Elasticsearch用Kibana看每个Node的耗时分布可以在retrieve_node里加断点用pdb单步调试向量检索逻辑甚至可以把trace导出为JSON用另一个Agent分析失败模式。这种深度可观测性在OpenClaw里要靠日志解析在ZeroClaw里依赖YAML结构在Codex里只能看CLI输出——唯独LangGraph把调试能力刻进了DNA。实操心得LangGraph不是万能胶它最怕“状态爆炸”。当你的GraphState里塞了10个字段、每个字段都是GB级数据时序列化/反序列化开销会拖垮性能。我的经验是状态只存必要ID如document_ids而非documents大数据操作用外部存储S3/Redis状态里只存key复杂分支逻辑用子图Subgraph隔离避免主图臃肿它最适合需要严格质量管控的场景如医疗问答、法律咨询多模型协同的复杂推理检索生成验证修正团队需共建、可审计、可复现的AI应用如风控决策引擎2.4 Codex从“代码生成器”到“带审批流的任务执行体”很多人以为Codex只是GitHub Copilot的后台其实它早已进化。最新版Codex CLIv2.4的核心定位是成为开发者身边的“可信任务代理”。它不做抽象的Agent框架而是聚焦一个具体问题如何让开发者安全、高效地把LLM生成的代码变成真实世界的动作Codex CLI的工作流极其务实你输入自然语言指令codex run 把/data/logs/2024-06目录下所有ERROR日志提取出来按服务名分组统计次数生成report.csvCodex分析意图生成完整Python脚本含错误处理、日志记录关键一步它不直接执行而是输出diff和plan$ codex run ... --- PLAN --- 1. Read all .log files in /data/logs/2024-06/ 2. Parse lines matching ERROR 3. Extract service name (e.g., auth-service from [auth-service]) 4. Count per service 5. Write CSV to /tmp/report.csv --- DIFF --- with open(/tmp/report.csv, w) as f: writer csv.writer(f) writer.writerow([service, count]) for svc, cnt in counts.items(): writer.writerow([svc, cnt])你审查plan和diff确认无误后输入yCodex才执行执行后输出结构化结果{status: success, output_file: /tmp/report.csv, rows_written: 127}这种设计把“信任”拆解为可验证的步骤。我在某物联网公司做边缘计算Agent时用Codex CLI替代了原来的手动脚本编写。运维同事反馈“以前改个日志分析脚本得先找开发写再自己测试现在我直接用自然语言描述看懂diff就敢点y出了问题也能立刻定位是哪行代码写的”。Codex的离线能力也值得强调。它支持codex offline-pack命令把模型、工具链、常用Skill打包成单个二进制文件50MB可部署在无网络的工业网关上。某次客户产线升级我们把Codex离线包烧录到PLC旁的树莓派用语音指令通过ASR转文本触发设备诊断脚本——整个过程不依赖云端符合等保三级要求。注意Codex不是通用Agent框架它没有Skill注册、没有YAML编排、没有图计算。它的优势场景非常聚焦开发者日常运维日志分析、配置生成、数据清洗边缘计算场景离线、低资源、强安全需要“人机共责”的任务每步执行前需人工确认如果你要构建面向终端用户的智能体如微信AI助手Codex的CLI交互模式就不合适了。3. 实操选型决策树从场景出发而非从框架出发3.1 先画清你的“动作地图”再选框架选型失败的根源往往始于问题定义不清。我建议你拿出一张白纸按以下三步画出专属的“Agent动作地图”第一步列出所有要自动化的动作Action不要写“提升客服效率”要写具体动作✅ 动作1解析微信用户消息提取订单号、退货原因、图片附件✅ 动作2调用ERP API查询该订单状态和商品库存✅ 动作3根据退货政策规则引擎判断是否可退✅ 动作4若可退生成退款单、通知仓库、发送微信模板消息❌ 避免 “优化用户体验”、“实现智能化”第二步为每个动作标注三个关键属性动作是否变更真实环境是否需多人审批是否需审计追溯解析微信消息否只读否是需存原始消息调用ERP API是查库存否是需存API请求/响应生成退款单是写数据库是财务客服双签是需完整操作日志发送微信消息是调用公众号API否是需存发送记录第三步匹配框架能力矩阵把你的标注结果对照框架的核心能力能力维度OpenClawZeroClawLangGraphCodex变更真实环境✅ 强沙箱审批流⚠️ 仅限预置Action❌ 需自行实现Node✅ CLI沙箱approval多人审批✅ 原生支持RBAC集成❌ 无审批概念❌ 需自研Node⚠️ 单人确认CLI交互审计追溯✅ 结构化日志操作快照✅ YAML版本执行日志✅ 完整trace状态快照✅ plan/diff执行结果低代码编排❌ 需开发Skill✅ YAML声明式❌ 需写Python⚠️ CLI自然语言有限离线部署✅ DockerK8s✅ 二进制包⚠️ 需自备模型✅ 离线包50MB举个真实案例某连锁药店要做“处方药智能审核Agent”。他们的动作地图显示查阅国家药品目录只读需审计→ 所有框架都OK调用HIS系统获取患者过敏史只读需审计→ 所有框架都OK生成审核意见并写入HIS写操作需药师审方药师双审批→ 只有OpenClaw原生支持双签生成用药指导PDF并发给患者写操作需存PDF哈希值供追溯→ OpenClaw和Codex都能满足最终他们选了OpenClaw因为“双审批”是监管硬性要求其他框架要么无法满足要么要花3人月自研审批模块——这笔账算下来OpenClaw的学习成本反而更低。3.2 避开四个致命的认知陷阱在17个Agent项目中有6个初期选型错误根源是掉进了这些认知陷阱陷阱1“Star数成熟度”LangChain GitHub Star 58kLangGraph 24kOpenClaw 3.2k。但Star数反映的是社区热度不是生产就绪度。OpenClaw的3.2k Star里有1200来自金融/医疗客户他们贡献的PR全是安全加固、审计增强、国密算法支持——这些代码不会让你的Demo更炫但能让系统过等保测评。而LangGraph的24k Star里大量是学生和爱好者提交的玩具Demo。选型时要看/examples/production/目录是否存在看CI/CD pipeline是否包含渗透测试而不是盲目追Star。陷阱2“文档全易上手”ZeroClaw文档只有20页全是YAML示例LangGraph文档200页涵盖图理论、状态管理、异步调度。表面看ZeroClaw更友好但实际落地时我们发现ZeroClaw的YAML语法糖如{{ now|date(%Y%m%d) }}在复杂条件判断时极易出错且错误提示晦涩Jinja2 TemplateSyntaxErrorLangGraph的长文档恰恰是它的护城河——它把所有边界情况如状态循环、Node超时、分布式锁都写清楚了省去了你踩坑的时间我的建议新手从ZeroClaw入门做运维脚本但一旦进入业务核心系统立刻切到LangGraph或OpenClaw。陷阱3“开源免费”Codex CLI是MIT协议但它的核心能力依赖OpenAI API。某客户用Codex做了个“自动写周报”Agent每月API账单超2万元——因为他们没意识到Codex的plan生成、diff分析、错误修复全在调用GPT-4 Turbo。而OpenClaw的Skill可以完全本地化用Qwen2.5-7B跑send_emailSkillZeroClaw的YAML执行不依赖LLM只在生成阶段需要。选型时务必核算TCO总拥有成本包括LLM调用费按token计费计算资源费GPU/CPU运维人力成本调试、监控、升级合规成本等保、GDPR、审计报告陷阱4“能跑Demo能上线”所有框架都能跑通“天气查询”Demo但生产环境要面对微信消息1秒内必须响应LangGraph的Node初始化延迟可能达300msERP接口平均响应800ms超时要降级OpenClaw的timeout和fallback是Skill级配置日志文件可能达10GBCodex的codex run会加载全文到内存OOM我在某物流客户项目中用LangGraph做的运单追踪Agent在压力测试时发现当并发50时retrieve_node的向量检索因内存不足频繁GC导致P99延迟飙升到8秒。解决方案不是换框架而是把向量库从FAISS换成Milvus并在Node里加缓存——这说明框架只是载体真正的挑战在工程细节。3.3 一份可直接抄作业的选型速查表根据你填写的“动作地图”对照此表快速锁定候选框架你的核心诉求首选框架关键理由需规避的风险必须满足金融/医疗等保要求所有写操作需双人审批完整审计OpenClaw唯一原生支持RBAC审批流操作快照的框架已通过多家银行等保三级测评避免用LangGraph自研审批开发周期不可控避免用Codex CLI其CLI交互不支持多角色运维团队要自主编排备份、监控、扩缩容无需写代码ZeroClawYAML声明式运维可直接编辑预置Action覆盖90%运维场景执行计划可预测避免用OpenClawSkill开发需DevOps懂Python避免用LangGraph需写大量Python代码构建多跳问答、风控决策等需严格质量管控的AI应用团队需共建可调试流程LangGraph图模型天然支持断点调试、trace分析、A/B测试状态管理清晰适合复杂逻辑避免用Codex其CLI模式无法支持多步骤状态流转避免用ZeroClaw其YAML不支持动态条件分支开发者日常提效日志分析、配置生成需离线、低资源、强安全CodexCLI交互直观plan/diff可验证离线包50MB可部署树莓派沙箱机制成熟避免用LangGraph其Python依赖多离线部署复杂避免用OpenClaw其K8s部署对小型团队过重实操心得没有“最好”的框架只有“最合适”的选择。我建议你用最小可行方案MVP验证对OpenClaw用openclaw init --templatefinance生成一个带审批流的模板接入你的ERP测试环境跑通一个退款单生成流程预计2天对ZeroClaw写一个3步YAML查磁盘-备份-压缩在测试服务器上跑通预计4小时对LangGraph用官方QuickStart把你的“多跳问答”逻辑拆成3个Node跑通trace预计1天对Codex用codex offline-pack生成离线包在树莓派上执行codex run ls -l /tmp预计2小时MVP的目标不是功能完整而是验证这个框架的调试方式、错误提示、部署流程是否符合你团队的技术直觉4. 四框架的安装、调试与避坑实战指南4.1 OpenClaw从零部署一个带审批流的生产环境OpenClaw的安装不是pip install而是一次基础设施配置。以下是我在客户私有云CentOS 7 K8s 1.22上的标准流程已沉淀为Ansible Playbook步骤1准备基础依赖# 安装系统级依赖OpenClaw沙箱需要 sudo yum install -y epel-release sudo yum install -y python39 python39-devel gcc-c make \ libseccomp-devel systemd-devel sqlite-devel # 创建专用用户安全最佳实践 sudo useradd -r -s /bin/false openclaw sudo mkdir -p /opt/openclaw/{skills,config,logs} sudo chown -R openclaw:openclaw /opt/openclaw步骤2安装OpenClaw核心v1.8.3# 切换到openclaw用户 sudo su -s /bin/bash -c cd /tmp \ curl -L https://github.com/openclaw/openclaw/releases/download/v1.8.3/openclaw-1.8.3-py39-linux-x86_64.tar.gz | tar xz \ cp openclaw-1.8.3/bin/* /usr/local/bin/ \ cp -r openclaw-1.8.3/lib/python3.9/site-packages/* /usr/local/lib64/python3.9/site-packages/ openclaw步骤3配置审批流关键OpenClaw的approval不是开关而是可编程的策略。编辑/opt/openclaw/config/approval.yaml# 支持LDAP/AD集成这里用文件认证演示 auth: type: file users: - username: fin-admin password_hash: $6$rounds656000$... # 用mkpasswd生成 roles: [finance, admin] - username: it-operator password_hash: $6$rounds656000$... roles: [it, operator] policies: - name: finance-write description: 财务系统写操作需双签 actions: [erp.update_order, erp.create_refund] required_roles: [finance, admin] # 必须两个不同角色 timeout_minutes: 30 - name: it-read description: IT系统只读操作即时通过 actions: [system.disk_usage, network.ping] required_roles: [it] auto_approve: true步骤4开发第一个Skillsend_email在/opt/openclaw/skills/send_email/下创建# skill.py from openclaw.skill import Skill import smtplib from email.mime.text import MIMEText class SendEmailSkill(Skill): def __init__(self): super().__init__( namesend_email, descriptionSend email via SMTP, required_permissions[smtp:send, contact:read], side_effects[writes to smtp server, reads from contact db], rollback_plan[delete sent email record] ) def execute(self, to: str, subject: str, body: str): # 从配置读取SMTP设置不硬编码 smtp_config self.config.get(smtp, {}) msg MIMEText(body) msg[Subject] subject msg[From] smtp_config.get(from) msg[To] to with smtplib.SMTP(smtp_config[host], smtp_config[port]) as server: server.starttls() server.login(smtp_config[user], smtp_config[password]) server.send_message(msg) # config.yamlSkill专属配置 smtp: host: smtp.exmail.qq.com port: 587 user: {{ secrets.SMTP_USER }} password: {{ secrets.SMTP_PASS }} from: aicompany.com步骤5注册Skill并测试# 注册Skill自动校验契约 sudo -u openclaw openclaw skill register /opt/openclaw/skills/send_email/ # 触发审批流测试 echo {to:testcompany.com,subject:Test,body:Hello} | \ sudo -u openclaw openclaw skill run send_email --wait-for-approval # 在另一终端用fin-admin登录审批 sudo -u openclaw openclaw approval list # 查看待批任务 sudo -u openclaw openclaw approval approve task_id --as fin-admin常见问题排查问题openclaw skill run报错Permission denied: /dev/shm原因沙箱需要/dev/shm挂载但某些容器环境未启用解决在K8s Pod spec中添加securityContext: {privileged: true}或挂载emptyDir到/dev/shm问题审批页面空白F12看到Failed to load resource: net::ERR_CONNECTION_REFUSED原因OpenClaw Web UI默认绑定127.0.0.1:8080需改配置解决编辑/opt/openclaw/config/web.yaml设host: 0.0.0.0重启服务避坑不要在Skill里用print()输出敏感信息如密码OpenClaw的日志会明文记录。用self.logger.info(sent to %s, to)代替。4.2 ZeroClaw用YAML搞定一个跨系统数据同步ZeroClaw的安装极简但YAML编写是艺术。以下是在Ubuntu 22.04上部署“MySQL到Elasticsearch同步”的全流程安装ZeroClawv0.9.2# 下载二进制官方推荐避免Python依赖冲突 curl -L https://github.com/zeroclaw/zeroclaw/releases/download/v0.9.2/zeroclaw_0.9.2_linux_amd64.tar.gz | tar xz sudo mv zeroclaw /usr/local/bin/ # 初始化工作区 mkdir -p ~/zeroclaw-workspace/{workflows,secrets} cd ~/zeroclaw-workspace编写同步YAMLsync_orders.ymlname: mysql_to_es_sync description: Sync orders from MySQL to Elasticsearch daily triggers: - cron: 0 3 * * * # 每天3点 - webhook: /api/sync/orders # 也支持Webhook触发 secrets: - name: MYSQL_CONN value: mysqlpymysql://user:{{ secrets.MYSQL_PASS }}db:3306/orders - name: ES_URL value: https://{{ secrets.ES_USER }}:{{ secrets.ES_PASS }}es:9200 steps: - name: fetch_new_orders action: database.query args: connection: {{ secrets.MYSQL_CONN }} query: | SELECT id, customer_id, total_amount, created_at FROM orders WHERE created_at DATE_SUB(NOW(), INTERVAL 1 DAY) output_key: orders - name: transform_orders action: python.transform args: code: | # ZeroClaw内置Python沙箱自动导入pandas import pandas as pd df pd.DataFrame(input_data) df[amount_usd] df[total_amount] * 7.2 # 人民币转美元 return df.to_dict(records) input_key: orders output_key: transformed_orders - name: index_to_es action: elasticsearch.bulk_index args: url: {{ secrets.ES_URL }} index: orders-2024 documents: {{ steps.transformed_orders.output }} depends_on: [transform_orders] - name: notify_success action: notification.webhook args: url: https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx payload: | { msgtype: text, text: { content: ✅ Orders sync completed. Processed {{ steps.index_to_es.output.success_count }} records