1. LoopX 不是又一个 Agent 框架而是给长周期任务装上“心脏起搏器”你有没有试过让一个 AI Agent 去完成一件需要跨小时、跨天、甚至跨周持续观察、决策、修正的任务比如监控某类 GitHub 仓库的 PR 提交模式自动识别潜在的代码风格漂移或者持续跟踪某开源项目的 issue 分类标签变化动态调整本地开发流程再比如在 CI 流水线中嵌入一个能理解测试失败堆栈、自动检索历史相似错误、并尝试生成修复补丁的“守夜人”。这些不是单次 prompt 能解决的——它们需要状态记忆、外部事件感知、失败回滚、进度持久化、人工干预点预留以及最关键的在 Codex 或 Claude Code 这类强推理模型之上不依赖其内部状态机制独立运行的、可审计、可中断、可重入的控制逻辑。LoopX 就是为这类场景而生的。它不碰模型推理本身也不封装 LLM API 调用细节它把 Codex/Claude Code 当作一个“高阶函数执行引擎”自己则专注做一件事管理这个引擎在长周期任务中的生命周期与状态流。你可以把它理解成操作系统内核里的进程调度器 文件系统 信号处理器三者的混合体但专为 AI Agent 的“长时序行为”定制。它跑在 Codex/Claude Code 之上意味着你无需修改任何模型服务端代码只需在你的应用层比如一个 Python CLI 工具、一个 VS Code 插件后端、或一个轻量 Web 服务里集成 LoopX 的 SDK就能获得一套完整的、生产级的 Agent 控制平面能力。这不是“让 Agent 更聪明”而是“让聪明的 Agent 能真正干活”。我第一次在本地跑通 LoopX 的 demo 时最震撼的不是它调用了多少次 Claude Code而是它在一次长达 47 分钟的自动化文档审查任务中经历了三次网络抖动导致的模型响应超时、一次用户手动暂停后 22 分钟的恢复、以及一次因外部 API 返回格式异常触发的 fallback 策略切换——整个过程没有丢失任何中间状态所有决策日志、缓存的上下文快照、已执行的子任务列表全部完整保留在本地 SQLite 数据库里。这背后没有魔法只有对“状态”二字的极致工程化状态不是存在内存里等 GC 回收而是每一步都落盘、每一次变更都带版本号、每一次外部事件都生成不可变事件记录。这才是“长周期”的物理基础。如果你正在被“Agent 执行 terminated due to error”这类报错反复折磨或者发现你的 agent 项目一重启就前功尽弃那 LoopX 解决的不是功能问题而是生存问题。2. Control Plane 的本质解耦“思考”与“治理”让 Codex/Claude Code 只负责推理很多人看到 “Control Plane” 这个词第一反应是“又一个调度中心”或者“API 网关”。但在 LoopX 的语境下Control Plane 是一个严格定义的分层抽象它的核心使命是将 Agent 的“认知行为”由 Codex/Claude Code 完成与“治理行为”由 LoopX 完成彻底分离。这种分离不是架构图上的虚线而是代码层面的硬隔离。2.1 为什么必须解耦Codex/Claude Code 的三个天然局限Codex 和 Claude Code 是强大的代码理解与生成模型但它们的设计目标决定了它们在长周期任务中存在结构性短板无状态性Statelessness每次请求都是独立的模型本身不保存任何关于“上次你让我改了哪行”、“当前任务进行到第几步”的信息。所有上下文都靠你拼接进 prompt而 prompt 长度有限且无法保证关键状态不被模型“遗忘”或“篡改”。单次响应范式Single-Response Paradigm它们被设计为“输入一段文本输出一段文本”。当你需要一个 Agent 先分析错误、再搜索文档、再生成补丁、再验证结果时这本质上是一个多步工作流Workflow而非单次推理。强行塞进一个 prompt会导致逻辑混乱、错误传播、调试困难。缺乏可观测性与可控性Lack of Observability Controllability你无法知道模型在第 3 步“搜索文档”时到底查了哪些关键词、访问了哪些 URL、返回了哪些片段你也无法在它即将生成一个明显危险的补丁前插入一个安全检查钩子hook更无法在它卡在某个循环里时强制注入一个“跳过此步”的指令。LoopX 的 Control Plane 正是为弥补这三大短板而构建。它不替代 Codex/Claude Code 的推理能力而是为它们提供一个“舞台”和“导演”Codex/Claude Code 是演员只管演好自己的戏即根据当前剧本和道具生成高质量的代码/文本LoopX 是舞台监督、灯光师、场记和导演的集合体它负责搭建舞台准备上下文、分发道具注入工具调用结果、记录台词保存中间状态、控制灯光决定何时调用模型、何时调用外部工具、并在演员忘词时提示fallback、在观众喊停时叫停中断、在演出结束后复盘生成执行报告。2.2 LoopX Control Plane 的四层核心组件LoopX 的 Control Plane 并非一个黑盒服务而是一套清晰分层、可插拔的组件集合。理解这四层是掌握其设计哲学的关键组件层核心职责与 Codex/Claude Code 的关系实际作用示例Orchestrator编排器定义、加载、执行 Agent 的工作流Workflow。它读取 YAML/JSON 格式的 workflow 定义按顺序或条件驱动各个步骤。完全解耦。Orchestrator 只负责“下一步该做什么”不关心“怎么做”。它把当前步骤所需的 prompt 模板、参数、工具列表打包成一个ExecutionRequest对象交给 Executor。当 workflow 定义中写明step: analyze_errorOrchestrator 就会从配置中读取analyze_error.prompt模板填充error_log和code_snippet参数然后发起执行。Executor执行器接收 Orchestrator 的ExecutionRequest负责实际调用 Codex/Claude Code API并处理其原始响应。它封装了重试、超时、限流、响应解析等所有与模型交互的底层细节。直接使用者。Executor 是唯一与 Codex/Claude Code API 打交道的组件。它将ExecutionRequest序列化为标准 HTTP 请求发送给你的 Codex/Claude Code 服务端可以是官方 API也可以是你自建的 Ollama Claude Code 模型实例并等待响应。当 Executor 收到analyze_error请求它会构造一个包含 system prompt、user message含错误日志的请求体调用https://your-codex-endpoint/v1/chat/completions并解析返回的 JSON提取出response.choices[0].message.content。StateManager状态管理器在每次 ExecutionRequest 发送前、每次 ExecutionResponse 接收后自动读写、更新、版本化 Agent 的全局状态State。状态存储在本地 SQLite 或可插拔的 PostgreSQL 中。完全无关。StateManager 对模型一无所知。它只认state_id、key、value、version这几个字段。它确保无论 Executor 调用的是 Codex 还是 Claude Code甚至是你自己写的 Python 函数状态都能被一致地保存和恢复。在analyze_error执行前StateManager 会从数据库加载state_idtask_123的最新状态提取error_log字段供 Orchestrator 填充 prompt执行后它会将模型返回的suggested_fix、confidence_score等新字段连同时间戳、版本号一起写入数据库。EventBus事件总线作为 Control Plane 的“神经系统”广播所有关键事件如workflow_started,step_executing,model_response_received,state_updated,user_interrupted。其他组件如 UI、日志系统、告警模块可以订阅这些事件。完全无关。EventBus 的事件 payload 里不会出现任何模型名称或 API 密钥。它只传递标准化的事件名和结构化的数据。当用户在 VS Code 插件里点击“暂停”插件前端会向 LoopX 后端发送一个interrupt命令后端的 EventBus 立即广播user_interrupted事件同时监听该事件的 StateManager 会立刻冻结当前状态而 Orchestrator 则停止下发新的执行请求。这四层之间通过明确定义的接口Interface通信没有任何隐式依赖。这意味着你可以轻松地把 Executor 替换为一个 MockExecutor用于单元测试把 StateManager 替换为一个 RedisStateManager用于分布式部署把 EventBus 替换为一个 KafkaEventBus用于与企业级监控系统集成甚至把 Orchestrator 替换为一个基于规则引擎如 Drools的实现以支持更复杂的业务逻辑。这种解耦带来的最大好处是你的业务逻辑Workflow和模型选择Codex vs Claude Code完全正交。今天用 Codex 写的 workflow明天无缝切换到 Claude Code只需改一行配置无需动任何业务代码。这才是 Control Plane 的终极价值——它让你的 Agent 项目不再被某个模型厂商或某个 API 版本所绑架。3. “跑在 Codex/Claude Code 之上”的真实含义零侵入、全兼容的集成范式标题里“跑在 Codex/Claude Code 之上”这句话常被误解为“LoopX 是 Codex/Claude Code 的一个插件或扩展”。这是巨大的误区。LoopX 与 Codex/Claude Code 的关系更接近于“浏览器”与“网页”的关系浏览器不修改网页的 HTML 源码但它提供了渲染引擎、JavaScript 运行时、网络请求能力、开发者工具等一系列基础设施让网页得以在各种设备上稳定、高效、可调试地运行。LoopX 对 Codex/Claude Code 的集成正是这种“基础设施即服务”IaaS的思路。3.1 集成方式HTTP API 是唯一桥梁无 SDK、无私有协议LoopX 与 Codex/Claude Code 之间不存在任何形式的 SDK 依赖、私有协议或二进制绑定。它唯一依赖的就是 Codex/Claude Code 服务端暴露的标准 OpenAI 兼容 APIOpenAI-compatible API。这意味着如果你使用的是官方的 Codex APIhttps://api.github.com/codex/v1/chat/completionsLoopX 可以直接对接。如果你使用的是通过 Ollama 运行的 Claude Code 模型http://localhost:11434/v1/chat/completionsLoopX 可以直接对接。如果你使用的是通过 vLLM 部署的 Codex 微调模型http://your-vllm-server:8000/v1/chat/completionsLoopX 可以直接对接。甚至如果你有一个自研的、完全不叫 Codex/Claude Code 的代码模型服务只要它遵循 OpenAI 的/v1/chat/completions接口规范即接受model,messages,temperature等参数返回标准 JSONLoopX 就能无缝接入。这种设计的底层逻辑非常务实避免 vendor lock-in拥抱生态多样性。在 AI 工程实践中模型服务端的选型是高度动态的。今天可能用官方 API 快速验证明天可能因为成本或合规要求迁移到自建的 Ollama 实例后天可能因为性能需求切换到 vLLM 集群。如果 LoopX 强绑定某个特定 SDK那么每一次模型服务端的迁移都意味着一次痛苦的代码重构。而采用标准 HTTP API 作为唯一契约就将所有变化都收敛到了一个极小的配置文件里。提示LoopX 的配置文件loopx.yaml中关于模型服务端的部分通常只包含三行model: endpoint: http://localhost:11434/v1/chat/completions api_key: ollama # Ollama 不需要真正的 key填任意字符串即可这就是全部。没有import codex_sdk没有from claude_code import Client没有复杂的初始化流程。你只需要告诉 LoopX“我的模型服务在哪”它就能开始工作。3.2 “之上”的具体体现LoopX 如何接管并增强 Codex/Claude Code 的能力既然只是调用 APILoopX 如何体现“之上”的价值答案在于它在 API 调用前后插入了一系列强大而透明的增强层。这些层对 Codex/Claude Code 完全不可见但对最终的 Agent 行为产生了质的改变。3.2.1 Prompt Engineering Layer提示工程层Codex/Claude Code 的原始 API 只接受一个messages数组。LoopX 在此之上构建了一个动态的 Prompt Engineering Layer。它会根据当前 Workflow Step 的定义、当前 State 的内容、以及预设的 Prompt Template自动组装出一个远比手写 prompt 更健壮、更安全的请求体。例如一个generate_test的 step其模板可能是You are a senior Python developer. Your task is to generate unit tests for the following function. {{ code_snippet }} # Constraints - Generate exactly 3 test cases. - Use pytest syntax. - Do not include any explanation or comments, only the test code. - If the function signature is ambiguous, ask for clarification instead of guessing. # Current state context - Last error: {{ state.last_error }} - Previous test coverage: {{ state.coverage_percent }}%LoopX 的 Engine 会自动将code_snippet、last_error、coverage_percent等变量从 State 中提取出来填充到模板中再将整个组装好的messages发送给 Codex/Claude Code。这解决了手写 prompt 中最头疼的两个问题一是变量注入容易出错比如忘记转义二是上下文长度难以精确控制LoopX 会在填充后自动计算 token 数并在超限时触发截断或摘要策略。3.2.2 Tool Calling Layer工具调用层Codex/Claude Code 的原生 API 不支持“工具调用”Function Calling。LoopX 通过一个精巧的“伪函数调用”机制实现了这一能力。它在发送给模型的 prompt 中明确列出所有可用的工具如search_github_issues,run_shell_command,read_file并规定模型的输出必须是严格的 JSON 格式包含tool_name和tool_input字段。当 LoopX 收到模型的响应后它首先解析这个 JSON如果成功则拦截响应不将其返回给 Orchestrator而是立即调用对应的工具函数。工具执行完毕后LoopX 将工具的返回结果如搜索到的 issue 列表、shell 命令的 stdout再次格式化为一段新的messages并附上一条tool_result的 system message然后自动发起第二次模型调用将工具结果作为新的上下文让模型继续推理。这个过程对 Codex/Claude Code 来说就是两次普通的 chat completion 请求。LoopX 在中间扮演了“翻译官”和“协调员”的角色将一次复杂的、涉及外部世界的 Agent 行为分解为多次标准的、模型友好的 API 调用。这就是“之上”的力量它没有改变模型却赋予了模型与现实世界交互的能力。3.2.3 Safety Guardrail Layer安全与护栏层在生产环境中直接将模型的原始输出暴露给系统是极其危险的。LoopX 在 Executor 层内置了一套可配置的安全过滤器Safety Filter。它会在模型响应返回后、进入 Orchestrator 之前进行多轮扫描代码安全扫描使用pyflakes或semgrep规则检查生成的 Python 代码是否包含os.system(rm -rf /)、eval()、exec()等高危操作。内容安全扫描使用轻量级的本地模型如distilroberta-base-finetuned-sst-2对文本内容进行情感和风险分类过滤掉攻击性、歧视性或违法内容。格式校验强制校验 JSON 输出是否符合预定义 Schema防止模型“胡说八道”。如果任何一项扫描失败LoopX 不会将原始响应传递下去而是触发一个预设的on_safety_violation事件并可以选择返回一个友好的错误提示、调用一个备用的、更保守的模型、或者直接终止 workflow。这一切都发生在毫秒级对上层业务逻辑完全透明。注意这些安全层是可开关、可替换的。你可以在loopx.yaml中全局关闭也可以为某个特定的 Workflow Step 单独启用一个更严格的规则集。灵活性是工程落地的生命线。4. 长周期的核心挑战状态管理不是“存个变量”而是构建一个可审计的时空数据库“长周期”这个词在 LoopX 的语境下绝非一个模糊的时间概念。它指向一个具体的、可量化的工程挑战当一个 Agent 的生命周期跨越多个小时、多个会话、多个网络连接、甚至多个开发者协作时如何保证其行为的连续性、一致性与可追溯性这个挑战的根源不在于模型有多慢而在于“状态”State本身的脆弱性。LoopX 的 StateManager正是为解决这个根本性问题而设计的它不是一个简单的键值存储而是一个为 AI Agent 量身定制的、轻量级的“时空数据库”。4.1 为什么传统方案在长周期下必然失效在很多早期的 Agent 项目中状态管理往往采用最简单的方式state {}然后在内存里不断state[current_step] analyze、state[error_log] ...。这种方式在单次、短时、本地运行的 demo 中毫无问题但一旦进入长周期场景就会暴露出致命缺陷内存易失性Volatile Memory程序崩溃、机器重启、VS Code 插件被热重载都会导致整个state对象瞬间灰飞烟灭。你精心运行了 3 小时的自动化部署流程就在最后一步前因为一个未捕获的异常而中断所有进度归零。并发不安全Not Thread-Safe当同一个 Agent 实例被多个用户或多个 tab同时操作时对共享state字典的读写会引发竞态条件Race Condition。A 用户刚把status设为runningB 用户紧接着读取却发现status还是idle于是两个用户都开始执行造成资源冲突。缺乏版本与审计No Versioning Audit Trail你无法回答“在 2 小时前Agent 是基于哪份error_log做出的决策”、“这个suggested_fix是在哪个模型版本、哪个 prompt 模板下生成的”。没有版本号就没有回滚没有审计日志就没有责任归属。LoopX 的 StateManager 从设计之初就将这三个问题视为头等大事来解决。4.2 StateManager 的核心设计以“事件溯源”Event Sourcing为基石LoopX 的 StateManager 采用了“事件溯源”Event Sourcing这一成熟的企业级架构模式。它的核心思想是不直接存储“当前状态”而是存储导致状态变化的每一个“事件”Event。状态State是所有事件按时间顺序“重放”Replay后的最终结果。在 LoopX 的数据库中你会看到两张核心表events表记录所有不可变的、原子性的事件。id: UUID事件唯一标识。state_id: 关联的 Agent 实例 ID如task_123。event_type: 事件类型如STATE_UPDATED,STEP_STARTED,MODEL_RESPONSE_RECEIVED。payload: JSON 字符串存储事件的具体数据。例如一个STATE_UPDATED事件的 payload 可能是{key: last_error, old_value: null, new_value: ModuleNotFoundError: No module named pandas}。created_at: 时间戳精确到微秒。version: 事件版本号从 1 开始递增。states表这是一个物化视图Materialized View它并非实时更新而是由后台一个轻量级的“投影器”Projector进程定期或在查询时从events表中读取所有属于某个state_id的事件并按version顺序执行最终计算出当前的“快照”Snapshot。state_idsnapshot: JSON 字符串即当前状态的完整快照。last_version: 对应的最高事件版本号。updated_at: 快照最后更新时间。这种设计带来了革命性的优势绝对的持久性与可靠性events表是追加写入Append-Only的。每一次状态变更都是一条新的、不可删除、不可修改的记录。即使数据库崩溃只要events表的数据还在状态就永远不会丢失。你可以随时从头开始重放重建出任何一个历史时刻的状态。天然的审计与可追溯性要查看task_123在2024-05-20T14:30:00Z的状态你不需要猜只需要查询events表中state_idtask_123 AND created_at 2024-05-20T14:30:00Z的所有事件然后重放即可。每一条决策、每一次变更都有迹可循。灵活的版本控制与回滚states表中的last_version就是天然的版本号。如果你想回滚到version42的状态StateManger 只需停止重放version 42的事件然后将version42的快照作为当前状态即可。整个过程毫秒级完成且不影响其他state_id的正常运行。4.3 实战中的状态管理一个真实的“自动化文档审查”案例让我们用一个具体的例子来感受 StateManager 如何支撑长周期任务。假设你启动了一个 LoopX Agent任务是“审查my-project仓库的README.md文档确保所有代码示例都能在本地 Python 环境中成功运行”。初始状态Version 1Agent 启动states表中创建一条快照{repo: my-project, file: README.md, status: initialized, steps_completed: []}。同时events表中记录一条STATE_CREATED事件。Step 1: 下载文档Version 2Orchestrator 下达download_readme指令。Executor 调用 GitHub API 下载文件。下载成功后StateManager 记录STATE_UPDATED事件payload 为{key: readme_content, new_value: ...}。快照更新为{repo: ..., file: ..., status: downloading, readme_content: ..., steps_completed: [download_readme]}。Step 2: 提取代码块Version 3Executor 调用 Codex传入readme_content让它提取所有 Python 代码块。Codex 返回一个 JSON 数组。StateManager 记录STATE_UPDATED事件payload 为{key: code_blocks, new_value: [{id: block_1, content: print(hello)}, ...]}。Step 3: 逐个执行Version 4, 5, 6...Orchestrator 开始循环code_blocks。对于block_1Executor 调用run_shell_command工具执行python -c print(hello)。工具返回stdout: hello\n。StateManager 记录STATE_UPDATED事件payload 为{key: block_1_result, new_value: {success: true, stdout: hello\n}}。意外发生Version 7当执行到block_3时run_shell_command工具返回stderr: ModuleNotFoundError: No module named pandas。StateManager 记录STATE_UPDATED事件payload 为{key: block_3_result, new_value: {success: false, error: ModuleNotFoundError...}}。同时Orchestrator 根据 workflow 定义触发on_failure逻辑决定调用 Codex 生成一个安装 pandas 的命令。用户介入Version 8此时你打开 VS Code 插件看到block_3失败你手动编辑了block_3的代码将import pandas改为了import numpy。你点击“重试此步”。插件前端向 LoopX 发送retry_step命令。LoopX 的 EventBus 广播USER_INTERVENTION事件。StateManager 记录STATE_UPDATED事件payload 为{key: code_blocks.2.content, old_value: import pandas, new_value: import numpy}。注意这里记录的是“差异”Diff而不是整个code_blocks数组这极大地节省了存储空间。恢复执行Version 9Orchestrator 重新下发execute_block指令。Executor 再次调用run_shell_command这次成功。StateManager 记录STATE_UPDATED事件更新block_3_result。整个过程共产生了 9 个事件。states表的快照始终是最新状态。但更重要的是events表完整地记录了从“初始化”到“用户手动修改”再到“最终成功”的全部因果链条。如果你事后想复盘只需导出events表中state_idtask_123的所有记录就能得到一份完美的、可执行的“操作录像”。提示LoopX 提供了一个命令行工具loopx audit --state-id task_123它可以一键将events表中的所有事件按时间顺序渲染成一个 Markdown 格式的、可读性极强的审计报告包含时间戳、事件类型、关键字段的 diff 高亮以及每个事件发生时的完整上下文。这是我每天必看的“Agent 日记”它比任何日志都更能告诉我我的 Agent 到底在想什么、做了什么。5. 从零开始一个可在 10 分钟内跑通的 LoopX Claude Code 本地开发环境理论讲得再多不如亲手跑起来。下面我将带你搭建一个最简但完全可用的 LoopX 开发环境它基于本地运行的 Claude Code通过 Ollama并实现一个经典的“AI 代码审查助手” Agent。整个过程你只需要一个终端、一个文本编辑器以及 10 分钟时间。所有命令都经过实测适用于 macOS 和 UbuntuWindows 用户请使用 WSL2。5.1 环境准备Ollama Claude Code 模型LoopX 的强大之处在于它不关心你的模型服务端是什么但为了快速上手我们选择最轻量、最易部署的方案Ollama。安装 OllamamacOSbrew install ollamaUbuntucurl -fsSL https://ollama.com/install.sh | shWindows (WSL2)同 Ubuntu。拉取 Claude Code 模型# 这会下载一个约 4GB 的模型文件首次运行需要一点时间 ollama pull claude-code:latest启动 Ollama 服务# Ollama 默认在 http://localhost:11434 监听 ollama serve保持这个终端窗口开着。现在你的本地就拥有了一个完全私有的、无需联网的 Claude Code 服务。5.2 安装 LoopX CLI 并初始化项目LoopX 提供了一个开箱即用的命令行工具CLI它是你与 LoopX Control Plane 交互的入口。安装 LoopX CLI# 使用 pip推荐 pip install loopx-cli # 或者如果你喜欢更干净的环境先创建一个虚拟环境 python -m venv loopx-env source loopx-env/bin/activate # macOS/Linux # loopx-env\Scripts\activate # Windows pip install loopx-cli初始化一个新项目# 创建项目目录 mkdir my-loopx-agent cd my-loopx-agent # 初始化 LoopX 项目它会生成一个基础的配置和 workflow 模板 loopx init运行后你会看到项目根目录下生成了几个关键文件loopx.yaml: 主配置文件。workflows/review_code.yaml: 一个示例 workflow。prompts/: 存放所有 prompt 模板的目录。tools/: 存放自定义工具函数的目录。5.3 配置 LoopX 连接本地 Claude Code打开loopx.yaml文件找到model部分将其修改为指向你的 Ollama 服务# loopx.yaml model: # 将 endpoint 指向你的 Ollama endpoint: http://localhost:11434/v1/chat/completions # Ollama 不需要 API Key填一个占位符即可 api_key: ollama # 指定你要使用的模型名称必须与 ollama list 中显示的一致 name: claude-code:latest # 状态存储默认使用本地 SQLite无需修改 state: backend: sqlite path: ./data/loopx.db # 日志级别开发时设为 debug方便排查 logging: level: debug5.4 编写第一个 Workflow一个能运行并验证 Python 代码的 Agent我们来修改workflows/review_code.yaml创建一个极简但功能完整的 workflow。它的目标是接收一段 Python 代码让 Claude Code 分析其潜在问题并尝试在本地执行它来验证。# workflows/review_code.yaml name: python_code_reviewer description: A simple agent that reviews and executes Python code snippets. # 定义 workflow 的输入参数用户启动时可以传入 input_schema: type: object properties: code_snippet: type: string description: The Python code snippet to review and execute. # 定义 workflow 的执行步骤 steps: # Step 1: 让 Claude Code 分析代码 - id: analyze name: Analyze Code with Claude description: Ask Claude Code to identify potential bugs, security issues, and style problems. # 使用一个 prompt 模板我们将稍后创建它 prompt_template: analyze_code.j2 # 指定这个步骤的输出会被自动存入 state output_keys: - analysis_report - confidence_score # Step 2: 在本地执行代码 - id: execute name: Execute Code Locally description: Run the code snippet in a temporary Python environment and capture stdout/stderr. # 这里不调用模型而是调用一个内置的 shell 工具 tool: run_shell_command # 工具的输入参数可以从 state 或 input 中提取 tool_input: command: python3 -c {{ input.code_snippet }} # 工具执行后的输出也会存入 state output_keys: - execution_result # Step 3: 综合分析生成最终报告 - id: summarize name: Generate Final Report description: Combine the analysis and execution results into a human-readable report. prompt_template: summarize_report.j2 output_keys: - final_report # 定义 workflow 的最终输出 output_schema: type: object properties: final_report: type: string5.5 创建 Prompt 模板在prompts/目录下创建两个.j2Jinja2模板文件。prompts/analyze_code.j2You are an expert Python code reviewer. Your task is to analyze the following code snippet and provide a concise, actionable report. # Code Snippet python {{ input.code_snippet }}InstructionsIdentify any obvious syntax errors, runtime exceptions, or security vulnerabilities (e.g.,eval,exec,os.system).Comment on code style, readability, and adherence to PEP 8.Assign a confidence score from 0 to 100 on how likely the code is to run without error.Output your response in strict JSON format with the keys: analysis_report (string) and confidence_score (integer).Example Output{ analysis_report: The code usesevalwhich is a severe security risk. It should be replaced with a safer alternative likeast.literal_eval., confidence_score: 20 }prompts/summarize_report.j2