Agent Zero parallel 工具深度解析独立工具调用并行化、Job 生命周期与源码实现【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zeroAgent Zero 的parallel是面向模型驱动的并发执行工具它把多个相互独立的工具调用打包成一批同时启动随后可按 Job ID 等待await、收集collect或取消cancel用于显著压缩长链式 Agent 任务的等待时间。本文以 tools/parallel.py.dox.md 为骨架结合 tools/parallel.py、helpers/parallel_tools.py 与 tests/test_parallel_tool.py 的源码级证据完整讲解工具的参数契约、Job 生命周期、后台执行模型、限制规则与验证方式读完即可理解并复现该工具的全部行为。一、职责边界三个文件如何分工parallel功能的代码刻意保持目录扁平化职责被拆成三个紧密同步的部分文件职责tools/parallel.py定义ParallelTool继承helpers.tool.Tool负责参数入口、execute分发与结果写入历史helpers/parallel_tools.py承载共享执行逻辑Job 数据结构、启动/等待/取消/清理、后台 worker 运行、结果格式化prompts/agent.system.tool.parallel.md模型提示词契约定义参数形态、使用规则与 JSON 示例与工具行为保持一致从源码结构看tools/parallel.py是薄壳它的execute几乎不做业务逻辑只做动作分发cancel/ 启动新 Job /await真正的并发调度全部落在helpers/parallel_tools.py。这也符合 DOX 文档中避免在工具文件内添加工具专属执行逻辑共享执行行为属于helpers/parallel_tools.py的维护约定。ParallelTool实现了三个生命周期方法class ParallelTool(Tool): async def before_execution(self, **kwargs): # self.log None不产生自身日志行 async def after_execution(self, response, **kwargs): # 写入模型历史 hist_add_tool_result async def execute(self, **kwargs) - Response: # 参数解析 动作分发其中before_execution将self.log置空、after_execution仅把结果写进模型历史——这正是wrapper 自身不产生可见过程日志可见日志行由每个子 Job 各自拥有这一契约的实现来源。二、参数契约与三种典型调用方式parallel的参数集合如下来自 prompts/agent.system.tool.parallel.md 与 helpers/parallel_tools.py参数类型默认值说明tool_calls数组或 JSON 字符串无要并行启动的独立工具调用列表别名calls、items等价job_ids字符串或字符串数组无等待/收集/取消已有 Job 的 IDwaitbooltrue是否等待 Job 完成false表示后台启动稍后用job_ids收集actionstart/await/collect/cancel无动作语义见下文状态机timeoutint秒300本次调用最多等待多久只限制等待不取消仍在运行的 Job示例 1启动一批并等待最常用来自提示词契约原文{ tool_name: parallel, tool_args: { tool_calls: [ {tool_name: call_subordinate, tool_args: {message: Review option A and return key risks., reset: true}}, {tool_name: search_engine, tool_args: {query: official API changelog release notes}} ], wait: true } }注意这里把两个不同工具call_subordinate与search_engine放进同一批正是文档强调的即使使用不同工具独立调用也应共享一个 batch只有依赖、顺序、共享可变状态或父上下文状态/工具可用性变化时才拆分。示例 2仅收集已有 Job不等待仍在运行的{tool_name: parallel, tool_args: {action: await, job_ids: [job-id], timeout: 300}}示例 3后台启动后稍后回收wait: false时执行逻辑见 tools/parallel.py{ tool_name: parallel, tool_args: { tool_calls: [{tool_name: code_execution_tool, tool_args: {runtime: terminal, code: pwd}}], wait: false } }wait: false且未提供job_ids时工具返回format_started_jobs生成的 JSONstatus: started Job 快照并附带提示Use the parallel tool with job_ids to await or cancel these background jobs.三、使用规则与硬性限制DOX 文档与提示词契约共同确立了以下边界其中多条由源码直接强制仅限独立调用依赖步骤、有序步骤、共享可变状态、必须在父上下文发生的状态/工具可用性变化一律保持顺序执行不得打包。document_query被强制排除DISALLOWED_PARALLEL_TOOLS {document_query, response}helpers/parallel_tools.py原因是它对并行 worker 来说太重必须顺序调用。response被强制排除被包裹的response无法结束父消息循环最终响应必须作为顶层调用出现。禁止嵌套parallel归一化阶段直接抛错 parallelcannot be nested inside anotherparallelcall此外 extensions/python/tool_execute_before/_20_block_parallel_recursion.py 作为tool_execute_before扩展在直接后台工具 worker内部再次调用parallel时抛出RepairableExceptionTheparalleltool cannot be used inside a parallel worker。call_subordinate的特殊语义在parallel内启动call_subordinate会在父 chat 之下创建隔离的子 chatAgentContextType.USER而不是调度器任务测试test_parallel_child_contexts_are_chats_not_tasks验证了子上下文以parent_context_id挂在父上下文下且不出现在任务列表中。递归防护的分界is_parallel_worker()依据上下文中的PARALLEL_WORKER_KIND_KEY判断——值为tool时阻断递归值为subordinate时放行子 chat 可正常使用包括parallel在内的普通工具。测试test_parallel_recursion_guard_allows_subordinate_children_but_blocks_tool_workers完整覆盖了这一分界。四、Job 生命周期与状态机ParallelJobhelpers/parallel_tools.py是并发的核心数据单元字段包括id、parent_context_id、index、tool_name、tool_args、kind、state、created_at/started_at/completed_at、result/error、worker_context_id、log_id与deferred_task。状态集合pending → running → success | error | cancelled | timeoutTERMINAL_STATES {success, error, cancelled, timeout}。Job 类型tool直接工具 worker与subordinate子 chat worker。四种 action 语义对应 tools/parallel.pyactionstart启动tool_calls中的 Job是否等待由wait决定actionawait别名wait等待指定job_ids直到完成或timeout超时不取消 Job返回仍在运行的 Job 句柄快照带wait_timed_out: true可再次awaitactioncollect不等待直接返回当前快照含仍running的 Job用于中途盘点actioncancel对指定job_ids请求取消——kill()底层DeferredTask标记cancelled并从 Job 存储中移除。默认 wait 逻辑容易误解的点wait_default action not in {start, background, collect}即除这三个 action 外wait默认true而action为await/wait时强制wait true。timeout 的边界语义在测试test_parallel_await_timeout_keeps_running_jobs_awaitable中被严格锁定超时后 Job 的deferred_task未被 kill、仍留在 Job 存储中返回快照state running且wait_timed_out true负载中status waiting并附带指令提示可再次await或cancel。这正是文档强调的timeout只限制本次调用等待多久运行中的 Job 继续执行可凭job_ids再次等待。五、参数归一化与输入校验parallel对输入做多层容错与校验全部位于 helpers/parallel_tools.py列表别名extract_tool_calls依次检查tool_calls、calls、items三个键取第一个存在者。JSON 字符串容错normalize_parallel_tool_calls接受合法 JSON 字符串编码的调用列表用于 provider/模型恢复场景解析失败抛 tool_callsmust be an array of normal tool-call objects.测试test_normalize_parallel_tool_calls_accepts_json_string_array验证了带headline等规划字段的字符串输入可正常解析。数量约束列表必须非空且最多DEFAULT_MAX_CALLS 8个元素。调用对象形态每个 item 复用与顶层回复一致的tool_name/tool_args形态经 helpers/extract_tools.py 的normalize_tool_request归一化——它兼容tool/args、type: functionname/parameters、tool_name: tool:action方法后缀自动补action以及method字段转action规划字段thoughts、headline等被忽略。测试test_normalize_parallel_tool_calls_accepts_normal_tool_request_shapes验证了text_editor:read与{tool, args}两种形态。job_ids 归一化normalize_job_ids接受单个字符串或字符串数组其他类型抛错。bool/超时强转coerce_bool支持1/true/yes/on与0/false/no/off字符串coerce_timeout要求正整数秒默认DEFAULT_TIMEOUT_SECONDS 300非法值抛 timeoutmust be an integer number of seconds。六、后台执行模型两种 Worker 的源码拆解start_parallel_jobshelpers/parallel_tools.py为每个调用创建ParallelJobcall_subordinate→kindsubordinate其余 →kindtool把 Job 写入父上下文存储键_parallel_jobs在启动前调用_log_parallel_child_started生成可见子日志行然后以DeferredTask(thread_nameTHREAD_BACKGROUND)在后台线程启动_run_parallel_job——这就是可见子行由helpers/parallel_tools.py在后台 Job 开始前发出的落点。直接工具 Workertool_run_direct_tool_job创建AgentContextType.BACKGROUND的 worker 上下文克隆父配置写入_parallel_job_id/_parallel_worker_kind等数据键随后调用execute_tool_call执行完整工具调用链解析工具先查 MCP 工具MCPConfig.get_instance().get_tool失败则回退agent.get_tool→before_execution→tool_execute_before扩展 →execute→tool_execute_after扩展 →after_execution期间穿插handle_intervention()中断检查。execute_tool_call内部同样对tool_name parallel直接抛错形成第二道嵌套防线。执行完成后 worker 上下文被_remove_context清理含persist_chat.remove_chat。子 chat Workersubordinate_run_subordinate_context_job创建AgentContextType.USER的子上下文支持profile/agent_profile参数通过_clone_config覆盖克隆配置中的 profile、attachments列表、自定义name缺省取 message 前 80 字符作为标签形如Parallel subordinate N。子 worker 获得专属系统提示You are running as an isolated parallel worker for a parent Agent Zero chat...Return a concise final textual summary for the parent.通过message_queue.log_user_message记录消息、hist_add_user_message注入用户消息、persist_chat.save_tmp_chat落盘然后执行worker_context.agent0.monologue()完成整个子对话循环并返回最终文本。子上下文的输出数据中写入parent_context_id/parent_context_kind: parallel/parallel_job_id等键——WebUI 侧栏据此把并行子 chat 渲染为父 chat 下的缩进手风琴列表对应测试test_chats_sidebar_projects_parallel_children_as_indented_accordion涉及 webui/components/sidebar/chats/chats-store.js 与 webui/components/sidebar/chats/chats-list.html。轮询与回收await_parallel_jobs以POLL_INTERVAL_SECONDS 0.5秒为周期调用refresh_parallel_jobs检查DeferredTask.is_ready()/is_alive()ready 则取回result()异常映射为error直到全部进入终态或到达 deadline。终态 Job 在collectTrue时被清理并从存储中移除。七、返回结果面向模型的紧凑 JSON所有结果都通过 JSON 返回刻意保持足够紧凑以节省消息历史同时保留job_id、状态与结果Job 快照_job_snapshot包含job_id、tool_name、state、duration_seconds精确到毫秒、可选context_id终态时附带result或error。结果负载format_parallel_results由status与jobs数组组成status的推导规则为存在活动 Job →waiting超时场景或running全部success→success全部cancelled→cancelled部分成功 →partial否则error。超时场景额外携带wait_timeout: true与instruction提示再次await或cancel。extras 提醒build_parallel_jobs_extras会把仍在运行与已就绪可收集的 Job 汇总成文本注入 agent 循环的 extras提醒模型在最终综合前先收集运行中的 Job 结果对应提示词契约第 15 条规则。日志模型wrapper 自身不写可见日志行test_parallel_tool_keeps_wrapper_out_of_visible_log验证context.log.items []结果仅经hist_add_tool_result进入模型历史每个子 Job 的日志行在启动前生成subordinate类型为subagent行tool类型优先复用目标工具自身的get_log_object()如code_execution_tool的code_exe行、wait的progress行回退为通用tool行Job 结束后由_update_parallel_child_log用结果文本或错误信息更新该日志行内容。八、测试验证与维护指引tests/test_parallel_tool.py 是parallel行为契约最直接的证明关键用例包括调用形态归一化普通形态、tool/args形态、JSON 字符串形态含规划字段被忽略拒绝嵌套parallel与拒绝document_query/response参数化测试extras 同时列出 running 与 ready Job超时不杀 Job、可再次 awaitwait_timed_out标志collect不等待不取消运行中 Jobcancel会 kill 后台任务并从存储移除递归防护tool worker 阻断、subordinate 子 chat 放行子日志类型subagent、通用tool、code_exe、progress子上下文以 chat 而非任务形态进入快照、侧栏以缩进手风琴展示并行子 chat。DOX 文档给出的维护指引是任何涉及工具参数或输出变更需同步协调 prompts/agent.system.tool.parallel.md、提示词契约测试与 helper 测试改动后用真实 WebUI 或 CLI 会话调用parallel并携带多个子 Job 做冒烟验证。由于目录刻意扁平tools/parallel.py与tools/parallel.py.dox.md必须保持同步演进。结语parallel是 Agent Zero 中并发编排能力的唯一入口其设计精髓在于参数层充分容错别名、JSON 字符串、多种调用形态语义层严格区分start/await/collect/cancel与超时不取消的等待边界执行层以DeferredTask后台线程承载隔离上下文并通过递归防护与document_query/response排除清单守住正确性底线。理解这套 Job 生命周期与 worker 模型是安全、高效地在自己的 Agent 工作流中编排并行工具调用的前提。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Agent Zero parallel 工具深度解析：独立工具调用并行化、Job 生命周期与源码实现
Agent Zero parallel 工具深度解析独立工具调用并行化、Job 生命周期与源码实现【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zeroAgent Zero 的parallel是面向模型驱动的并发执行工具它把多个相互独立的工具调用打包成一批同时启动随后可按 Job ID 等待await、收集collect或取消cancel用于显著压缩长链式 Agent 任务的等待时间。本文以 tools/parallel.py.dox.md 为骨架结合 tools/parallel.py、helpers/parallel_tools.py 与 tests/test_parallel_tool.py 的源码级证据完整讲解工具的参数契约、Job 生命周期、后台执行模型、限制规则与验证方式读完即可理解并复现该工具的全部行为。一、职责边界三个文件如何分工parallel功能的代码刻意保持目录扁平化职责被拆成三个紧密同步的部分文件职责tools/parallel.py定义ParallelTool继承helpers.tool.Tool负责参数入口、execute分发与结果写入历史helpers/parallel_tools.py承载共享执行逻辑Job 数据结构、启动/等待/取消/清理、后台 worker 运行、结果格式化prompts/agent.system.tool.parallel.md模型提示词契约定义参数形态、使用规则与 JSON 示例与工具行为保持一致从源码结构看tools/parallel.py是薄壳它的execute几乎不做业务逻辑只做动作分发cancel/ 启动新 Job /await真正的并发调度全部落在helpers/parallel_tools.py。这也符合 DOX 文档中避免在工具文件内添加工具专属执行逻辑共享执行行为属于helpers/parallel_tools.py的维护约定。ParallelTool实现了三个生命周期方法class ParallelTool(Tool): async def before_execution(self, **kwargs): # self.log None不产生自身日志行 async def after_execution(self, response, **kwargs): # 写入模型历史 hist_add_tool_result async def execute(self, **kwargs) - Response: # 参数解析 动作分发其中before_execution将self.log置空、after_execution仅把结果写进模型历史——这正是wrapper 自身不产生可见过程日志可见日志行由每个子 Job 各自拥有这一契约的实现来源。二、参数契约与三种典型调用方式parallel的参数集合如下来自 prompts/agent.system.tool.parallel.md 与 helpers/parallel_tools.py参数类型默认值说明tool_calls数组或 JSON 字符串无要并行启动的独立工具调用列表别名calls、items等价job_ids字符串或字符串数组无等待/收集/取消已有 Job 的 IDwaitbooltrue是否等待 Job 完成false表示后台启动稍后用job_ids收集actionstart/await/collect/cancel无动作语义见下文状态机timeoutint秒300本次调用最多等待多久只限制等待不取消仍在运行的 Job示例 1启动一批并等待最常用来自提示词契约原文{ tool_name: parallel, tool_args: { tool_calls: [ {tool_name: call_subordinate, tool_args: {message: Review option A and return key risks., reset: true}}, {tool_name: search_engine, tool_args: {query: official API changelog release notes}} ], wait: true } }注意这里把两个不同工具call_subordinate与search_engine放进同一批正是文档强调的即使使用不同工具独立调用也应共享一个 batch只有依赖、顺序、共享可变状态或父上下文状态/工具可用性变化时才拆分。示例 2仅收集已有 Job不等待仍在运行的{tool_name: parallel, tool_args: {action: await, job_ids: [job-id], timeout: 300}}示例 3后台启动后稍后回收wait: false时执行逻辑见 tools/parallel.py{ tool_name: parallel, tool_args: { tool_calls: [{tool_name: code_execution_tool, tool_args: {runtime: terminal, code: pwd}}], wait: false } }wait: false且未提供job_ids时工具返回format_started_jobs生成的 JSONstatus: started Job 快照并附带提示Use the parallel tool with job_ids to await or cancel these background jobs.三、使用规则与硬性限制DOX 文档与提示词契约共同确立了以下边界其中多条由源码直接强制仅限独立调用依赖步骤、有序步骤、共享可变状态、必须在父上下文发生的状态/工具可用性变化一律保持顺序执行不得打包。document_query被强制排除DISALLOWED_PARALLEL_TOOLS {document_query, response}helpers/parallel_tools.py原因是它对并行 worker 来说太重必须顺序调用。response被强制排除被包裹的response无法结束父消息循环最终响应必须作为顶层调用出现。禁止嵌套parallel归一化阶段直接抛错 parallelcannot be nested inside anotherparallelcall此外 extensions/python/tool_execute_before/_20_block_parallel_recursion.py 作为tool_execute_before扩展在直接后台工具 worker内部再次调用parallel时抛出RepairableExceptionTheparalleltool cannot be used inside a parallel worker。call_subordinate的特殊语义在parallel内启动call_subordinate会在父 chat 之下创建隔离的子 chatAgentContextType.USER而不是调度器任务测试test_parallel_child_contexts_are_chats_not_tasks验证了子上下文以parent_context_id挂在父上下文下且不出现在任务列表中。递归防护的分界is_parallel_worker()依据上下文中的PARALLEL_WORKER_KIND_KEY判断——值为tool时阻断递归值为subordinate时放行子 chat 可正常使用包括parallel在内的普通工具。测试test_parallel_recursion_guard_allows_subordinate_children_but_blocks_tool_workers完整覆盖了这一分界。四、Job 生命周期与状态机ParallelJobhelpers/parallel_tools.py是并发的核心数据单元字段包括id、parent_context_id、index、tool_name、tool_args、kind、state、created_at/started_at/completed_at、result/error、worker_context_id、log_id与deferred_task。状态集合pending → running → success | error | cancelled | timeoutTERMINAL_STATES {success, error, cancelled, timeout}。Job 类型tool直接工具 worker与subordinate子 chat worker。四种 action 语义对应 tools/parallel.pyactionstart启动tool_calls中的 Job是否等待由wait决定actionawait别名wait等待指定job_ids直到完成或timeout超时不取消 Job返回仍在运行的 Job 句柄快照带wait_timed_out: true可再次awaitactioncollect不等待直接返回当前快照含仍running的 Job用于中途盘点actioncancel对指定job_ids请求取消——kill()底层DeferredTask标记cancelled并从 Job 存储中移除。默认 wait 逻辑容易误解的点wait_default action not in {start, background, collect}即除这三个 action 外wait默认true而action为await/wait时强制wait true。timeout 的边界语义在测试test_parallel_await_timeout_keeps_running_jobs_awaitable中被严格锁定超时后 Job 的deferred_task未被 kill、仍留在 Job 存储中返回快照state running且wait_timed_out true负载中status waiting并附带指令提示可再次await或cancel。这正是文档强调的timeout只限制本次调用等待多久运行中的 Job 继续执行可凭job_ids再次等待。五、参数归一化与输入校验parallel对输入做多层容错与校验全部位于 helpers/parallel_tools.py列表别名extract_tool_calls依次检查tool_calls、calls、items三个键取第一个存在者。JSON 字符串容错normalize_parallel_tool_calls接受合法 JSON 字符串编码的调用列表用于 provider/模型恢复场景解析失败抛 tool_callsmust be an array of normal tool-call objects.测试test_normalize_parallel_tool_calls_accepts_json_string_array验证了带headline等规划字段的字符串输入可正常解析。数量约束列表必须非空且最多DEFAULT_MAX_CALLS 8个元素。调用对象形态每个 item 复用与顶层回复一致的tool_name/tool_args形态经 helpers/extract_tools.py 的normalize_tool_request归一化——它兼容tool/args、type: functionname/parameters、tool_name: tool:action方法后缀自动补action以及method字段转action规划字段thoughts、headline等被忽略。测试test_normalize_parallel_tool_calls_accepts_normal_tool_request_shapes验证了text_editor:read与{tool, args}两种形态。job_ids 归一化normalize_job_ids接受单个字符串或字符串数组其他类型抛错。bool/超时强转coerce_bool支持1/true/yes/on与0/false/no/off字符串coerce_timeout要求正整数秒默认DEFAULT_TIMEOUT_SECONDS 300非法值抛 timeoutmust be an integer number of seconds。六、后台执行模型两种 Worker 的源码拆解start_parallel_jobshelpers/parallel_tools.py为每个调用创建ParallelJobcall_subordinate→kindsubordinate其余 →kindtool把 Job 写入父上下文存储键_parallel_jobs在启动前调用_log_parallel_child_started生成可见子日志行然后以DeferredTask(thread_nameTHREAD_BACKGROUND)在后台线程启动_run_parallel_job——这就是可见子行由helpers/parallel_tools.py在后台 Job 开始前发出的落点。直接工具 Workertool_run_direct_tool_job创建AgentContextType.BACKGROUND的 worker 上下文克隆父配置写入_parallel_job_id/_parallel_worker_kind等数据键随后调用execute_tool_call执行完整工具调用链解析工具先查 MCP 工具MCPConfig.get_instance().get_tool失败则回退agent.get_tool→before_execution→tool_execute_before扩展 →execute→tool_execute_after扩展 →after_execution期间穿插handle_intervention()中断检查。execute_tool_call内部同样对tool_name parallel直接抛错形成第二道嵌套防线。执行完成后 worker 上下文被_remove_context清理含persist_chat.remove_chat。子 chat Workersubordinate_run_subordinate_context_job创建AgentContextType.USER的子上下文支持profile/agent_profile参数通过_clone_config覆盖克隆配置中的 profile、attachments列表、自定义name缺省取 message 前 80 字符作为标签形如Parallel subordinate N。子 worker 获得专属系统提示You are running as an isolated parallel worker for a parent Agent Zero chat...Return a concise final textual summary for the parent.通过message_queue.log_user_message记录消息、hist_add_user_message注入用户消息、persist_chat.save_tmp_chat落盘然后执行worker_context.agent0.monologue()完成整个子对话循环并返回最终文本。子上下文的输出数据中写入parent_context_id/parent_context_kind: parallel/parallel_job_id等键——WebUI 侧栏据此把并行子 chat 渲染为父 chat 下的缩进手风琴列表对应测试test_chats_sidebar_projects_parallel_children_as_indented_accordion涉及 webui/components/sidebar/chats/chats-store.js 与 webui/components/sidebar/chats/chats-list.html。轮询与回收await_parallel_jobs以POLL_INTERVAL_SECONDS 0.5秒为周期调用refresh_parallel_jobs检查DeferredTask.is_ready()/is_alive()ready 则取回result()异常映射为error直到全部进入终态或到达 deadline。终态 Job 在collectTrue时被清理并从存储中移除。七、返回结果面向模型的紧凑 JSON所有结果都通过 JSON 返回刻意保持足够紧凑以节省消息历史同时保留job_id、状态与结果Job 快照_job_snapshot包含job_id、tool_name、state、duration_seconds精确到毫秒、可选context_id终态时附带result或error。结果负载format_parallel_results由status与jobs数组组成status的推导规则为存在活动 Job →waiting超时场景或running全部success→success全部cancelled→cancelled部分成功 →partial否则error。超时场景额外携带wait_timeout: true与instruction提示再次await或cancel。extras 提醒build_parallel_jobs_extras会把仍在运行与已就绪可收集的 Job 汇总成文本注入 agent 循环的 extras提醒模型在最终综合前先收集运行中的 Job 结果对应提示词契约第 15 条规则。日志模型wrapper 自身不写可见日志行test_parallel_tool_keeps_wrapper_out_of_visible_log验证context.log.items []结果仅经hist_add_tool_result进入模型历史每个子 Job 的日志行在启动前生成subordinate类型为subagent行tool类型优先复用目标工具自身的get_log_object()如code_execution_tool的code_exe行、wait的progress行回退为通用tool行Job 结束后由_update_parallel_child_log用结果文本或错误信息更新该日志行内容。八、测试验证与维护指引tests/test_parallel_tool.py 是parallel行为契约最直接的证明关键用例包括调用形态归一化普通形态、tool/args形态、JSON 字符串形态含规划字段被忽略拒绝嵌套parallel与拒绝document_query/response参数化测试extras 同时列出 running 与 ready Job超时不杀 Job、可再次 awaitwait_timed_out标志collect不等待不取消运行中 Jobcancel会 kill 后台任务并从存储移除递归防护tool worker 阻断、subordinate 子 chat 放行子日志类型subagent、通用tool、code_exe、progress子上下文以 chat 而非任务形态进入快照、侧栏以缩进手风琴展示并行子 chat。DOX 文档给出的维护指引是任何涉及工具参数或输出变更需同步协调 prompts/agent.system.tool.parallel.md、提示词契约测试与 helper 测试改动后用真实 WebUI 或 CLI 会话调用parallel并携带多个子 Job 做冒烟验证。由于目录刻意扁平tools/parallel.py与tools/parallel.py.dox.md必须保持同步演进。结语parallel是 Agent Zero 中并发编排能力的唯一入口其设计精髓在于参数层充分容错别名、JSON 字符串、多种调用形态语义层严格区分start/await/collect/cancel与超时不取消的等待边界执行层以DeferredTask后台线程承载隔离上下文并通过递归防护与document_query/response排除清单守住正确性底线。理解这套 Job 生命周期与 worker 模型是安全、高效地在自己的 Agent 工作流中编排并行工具调用的前提。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考