过去半年AI 编程工具的竞争焦点已经从“谁能写出更长的代码”转向“谁能把多个智能体编排得更好”。一个很典型的场景是你用 Codex 或 Claude Code 干活一开始只给一个明确的小任务但项目一大就需要让“写代码的 Agent”“查资料的 Agent”“做测试的 Agent”分头协作。也就是所谓 multi-agent workflow。但真正跑起来之后很多人会发现一个尴尬的事实模型本身写代码能力很强真正把人卡住的反而是工作流的配置。模型名写错就报 not supported上下文塞满就中断模型容量满就要换端点和模型config 文件加载失败又要从头排查。代码还没写几行人先被编排问题折磨得精疲力竭。Gigacode 正是在这个背景下出现的。它最初以 Show HN 的形式发布核心理念一句话就能讲完让模型自己写出 multi-agent workflow然后立刻运行它。听起来简单本质却是一个不小的范式切换——工作流不再是人写给机器看的配置文件而是模型对任务的自我拆解产物再由系统执行。本文不打算把它讲成玄学而是从工程角度拆解三件事它解决的是什么层面的问题模型为什么有能力“自己写”工作流以及如果你想在自己的项目里借鉴这种思路最小可行方案长什么样。同时会结合近期社区中大量出现的模型配置、上下文超限、容量报错等问题给出实际排查建议。1. 这篇文章真正要解决的问题先说结论Gigacode 这类设计解决的主要成本是“编排成本”不是“生成成本”。大模型生成代码已经不是瓶颈了。现在真正的瓶颈是当你需要多个模型节点协作时谁来设计它们之间的依赖关系、数据传递、重试策略和终止条件过去这件事靠人手工完成。你在 workflow 流程设计在线编辑器里拖节点在 config.toml 里填模型参数在代码里写 Python 调用来串联 Agent。每一步都是工程工作而且是非常容易被模型版本更新打破的工程工作。一个更现实的问题是这种手工编排出来的工作流往往带有个人的隐性假设。比如你认为写代码的 Agent 一次就能写对所以没有设计 Review 节点你认为模型的上下文窗口足够所以把大段代码全文传给下一个 Agent。这些假设一旦在真实运行中失效工作流就脆弱得像纸糊的一样。Gigacode 的做法是把“设计工作流”这件事本身交给模型。你只需要给出任务目标模型负责拆解步骤、声明每个 Agent 的职责、定义它们之间如何协作然后由运行器执行。人在这个链路里的角色从“写流程的人”变成了“定义目标和验收结果的人”。这篇文章适合三类读者正在用 Codex、Claude Code 等编程代理但被多智能体协作和配置问题反复折磨的人。对 multi-agent workflow 感兴趣想知道它到底是概念还是真能落地的人。想自己实现一个简单的 Agent 编排器而不是过度依赖某个封闭平台的人。读完之后你会理解 workflow 的通用结构知道模型自写工作流的关键约束并且能跑通一个最小示例。2. 从“人排工作流”到“模型排工作流”范式变化要理解 Gigacode 的价值必须先理解传统 multi-agent workflow 是什么以及它痛点在哪。传统做法是人先设计工作流再让模型去执行。这个过程很像写一个后端接口你要定义入参、出参、各步骤之间的依赖最后还要处理异常情况。差异只是把代码任务换成了 Agent 节点。比如一个简单的 Code Review 工作流至少需要三个节点代码生成节点、静态规则检查节点、模型 Reviewer 节点。人要把它们串起来还要决定失败时怎么办。这种模式的第一个问题是配置容易被模型版本打破。你在 config.toml 里写定了某个模型名但服务商更新了模型列表你的配置就失效了。近期社区里大量出现类似报错“model is not supported”“selected model is at capacity”“chatgpt 无法加载 config.toml”本质上都是同一个问题工作流配置和模型生态耦合太紧。第二个问题是上下文管理难。多 Agent 协作意味着信息要在节点间传递。最简单的传递方式是把上一个 Agent 的完整输出塞给下一个 Agent。但模型上下文窗口是有限的一旦累计内容超过最大值工作流就会中断。报错里常见的 context window 超限就是节点之间数据传得太多、太全、没有做摘要压缩导致的。第三个问题是脆弱性。手工配置的工作流通常按最理想情况设计缺少对模型输出异常、网络抖动、服务端限流的兜底。所以一个看起来很完整的工作流实际跑起来经常“agent terminated due to error”然后你需要手动重试或者重新开始。Gigacode 的思路和传统方式有本质区别它不是帮人更容易地写 workflow而是把 workflow 本身当作模型要生成的“产物”。对比维度传统手工编排模型自写工作流工作流设计者人模型配置与模型耦合度高模型一变配置就废低模型按 schema 动态生成对失败的容忍度低按理想情况设计高运行器把错误反馈给模型再调整人的主要工作写流程、调参数定义目标、写约束、验收结果主要风险手工配置维护成本高模型生成结果可能不符合 schema从工程角度看后者并不是取消了 workflow而是把 workflow 从一个“静态配置文件”变成一个“动态可执行产物”。这要求运行器具备把执行错误反馈给模型的能力形成闭环。3. 理解 multi-agent workflow概念拆解很多文章一上来就讲 LangGraph、AutoGen 的 API但读者连最基础的概念都没有对齐这并不好。在讨论 Gigacode 之前我们先用最小集把 multi-agent workflow 讲清楚。3.1 Agent 的基本构成一个 Agent 不是玄学它本质上是一个“能调用工具、能基于上下文生成决策”的模型实例。要让一个 Agent 真正在 workflow 里可用至少需要四样东西模型配置用什么模型、什么温度、什么上下文窗口。系统提示词定义它的角色和职责。可用工具列表它能够调用哪些函数或 API。输入输出约定从工作流的哪个节点接收数据输出什么样的结果。这里的第一个关键点Agent 是模型实例不等于模型本身。同一个模型可以起三个 Agent只要系统提示词和工具不同它们就会表现出不同行为。3.2 Workflow 的本质Workflow 描述的是 Agent 之间的执行顺序、依赖关系和失败策略。最理想的理解是把 Workflow 看成一张有向图节点是 Agent 或工具执行单元。边表示数据的传递方向。分支和循环表示条件判断和重试逻辑。一个简单的 workflow 可以是这样Research Agent 先产出需求分析Writer Agent 根据需求分析写代码Reviewer Agent 再审查代码。如果 Reviewer 发现问题工作流回到 Writer最多重试两次。这就是一个带循环的 DAG而不是一条直线。我们也可以拿 ComfyUI 来类比。ComfyUI 的 workflow 是把图像处理模型节点用连线串起来每个节点有输入输出。多智能体 workflow 的差别在于节点从“图像处理模型”换成了“大语言模型 Agent”连线里流动的数据也从张量换成了文本或结构化 JSON。3.3 运行器的角色有了图和节点还需要一个东西执行它这就是运行器。运行器负责按依赖顺序调度节点。把上一个节点的输出转换成下一个节点的输入。接收节点的错误并决定是否重试、回退或终止。对整个 workflow 做日志记录和 token 消耗统计。在 Gigacode 的语境里“the model writes its own multi-agent workflow, then runs it”中的后半句 “runs it”说的就是这个运行器。如果只有模型生成 workflow 但没有人执行那 workflow 就只是一张漂亮的图没有任何生产力价值。3.4 参数化与约束手动编排 workflow 时人会对每个 Agent 的具体参数负责。模型自动生成 workflow 时就必须把所有约束前置到一个 schema 里。所以问题变成了模型生成的 workflow 必须是一个结构良好的 JSON/YAML字段至少要覆盖 agent 名称、模型、系统提示词、工具列表、输入来源、输出去向、失败策略。任何字段缺失运行器都应该在运行前报 schema 错误而不是运行到一半才暴露。这就是模型自写工作流和传统自由文本生成的真正区别它要求模型遵守严格的格式相当于给模型的规划能力加了一条硬边界。3.5 为什么模型有“自己写”工作流的能力模型能生成 workflow底层依赖三个已经成熟的技术第一是函数调用。模型已经能够决定“什么时候调用什么工具”这说明模型具备把任务映射到工具调用的能力。定义 Agent 和依赖关系本质上是更大规模的工具调用规划。第二是结构化输出。通过 JSON Schema 约束模型可以稳定产出符合格式的复杂对象。Gigacode 要做的就是把 workflow 定义也纳入这一层。第三是任务分解能力。当前大模型在处理复杂任务时会先拆解成子任务再逐个执行。这其实就是模型层面的隐式 workflow。Gigacode 把这种隐式拆解显式化输出成可运行的 workflow 文件。这三个能力叠加结论就很清楚了让模型写 workflow 不是要不要做的问题而是工程上怎么约束、怎么执行、怎么兜底的问题。4. 一个典型场景从任务描述到工作流生成为了让你直观理解模型自写 workflow 的流程我们设计一个真实但可控的场景。假设任务目标是这样一句话“生成一个 Python 函数实现两个日期之间的工作日数量计算并补充单元测试。”如果让一个单 Agent 做这件事它会自己判断是否需要测试代码最大的问题是计划不透明。它可能写完函数就结束了也可能顺手写一个测试但没验证。如果采用多 Agent workflow我们可以这样拆解Research Agent分析需求输出函数签名和边界条件。Writer Agent根据研究结果写实现代码。Tester Agent为代码写单元测试。Reviewer Agent检查代码和测试是否一致质量问题则返工。传统方式中人要手写这段 workflow而且每个节点都要配模型名、提示词、输入输出字段。Gigacode 的理念是把这些节点的定义交给模型。模型在拿到任务描述后会生成一个 workflow 定义。这个定义至少包含{ workflow_name: date_workday_count, version: 1.0, nodes: [ { id: research, agent_name: requirement_analyst, model: your-model-name, description: 分析两个日期之间工作日统计需求输出函数签名与边界条件, input_from: [], output_to: [write] }, { id: write, agent_name: code_writer, model: your-model-name, description: 根据需求分析结果编写实现代码, input_from: [research], output_to: [review] }, { id: test, agent_name: test_writer, model: your-model-name, description: 为实现代码编写单元测试, input_from: [write], output_to: [review] }, { id: review, agent_name: code_reviewer, model: your-model-name, description: 检查代码与测试是否满足需求质量问题则返回 rework, input_from: [write, test], output_to: [write], max_retries: 2 } ] }注意这只是一个示意结构实际项目里你应该为它定义更严格的 JSON Schema。但你已经能看出 workflow 的核心信息全在这里节点、模型、输入输出依赖、重试次数。这就是“模型自写工作流”的产物。后面的问题只剩下谁来生成它谁负责执行它模型生成错了怎么办5. 最小可运行示例模型生成工作流并执行现在我们落到代码。下面这个最小示例分为三段工作流执行器、模型生成工作流、主流程串联。示例不依赖特定的 Agent 框架你只需要 Python 3.9 以上环境和 OpenAI 兼容的 API 客户端。5.1 项目目录结构gigacode-demo/ ├── runner.py ├── llm_client.py ├── main.py └── requirements.txt5.2 添加依赖openai1.30.0安装命令pip install -r requirements.txt5.3 执行器按依赖顺序运行节点这是最核心的部分。执行器不关心 workflow 是怎么来的它只负责解析 workflow、按拓扑顺序执行、并把错误反馈给调用方。# 文件路径gigacode-demo/runner.py from __future__ import annotations import json from typing import Any, Callable, Dict, List class WorkflowError(RuntimeError): 工作流执行异常 class AgentRunner: def __init__( self, node_action: Callable[[Dict[str, Any], Dict[str, Any]], Dict[str, Any]], ): self.node_action node_action self.outputs: Dict[str, Any] {} def execute(self, workflow: Dict[str, Any]) - Dict[str, Any]: nodes workflow[nodes] node_map {n[id]: n for n in nodes} ran: set[str] set() total_round 0 max_round len(nodes) * 5 # 防止死循环 while len(ran) len(node_map) and total_round max_round: total_round 1 progressed False for node in nodes: if node[id] in ran: continue input_from node.get(input_from, []) if not all(src in ran for src in input_from): continue # 聚合输入 inputs {src: self.outputs[src] for src in input_from} # 执行节点并支持重试 node_output self._run_with_retry(node, inputs) self.outputs[node[id]] node_output ran.add(node[id]) progressed True # 检测不可达节点若一轮没有节点执行说明存在循环依赖或依赖缺失 if not progressed: unrun [n[id] for n in nodes if n[id] not in ran] raise WorkflowError(f存在无法执行的节点或循环依赖: {unrun}) if len(ran) len(node_map): raise WorkflowError(执行轮次超过上限请检查 workflow 是否存在死循环) return self.outputs def _run_with_retry( self, node: Dict[str, Any], inputs: Dict[str, Any] ) - Dict[str, Any]: max_retries int(node.get(max_retries, 0)) last_error: Exception | None None for attempt in range(max_retries 1): try: return self.node_action(node, inputs) except Exception as e: last_error e if attempt max_retries: print(f[runner] 节点 {node[id]} 第 {attempt 1} 次执行失败准备重试) continue raise WorkflowError(f节点 {node[id]} 执行失败: {last_error}) def print_workflow_result(result: Dict[str, Any]) - None: print(json.dumps(result, ensure_asciiFalse, indent2))这段代码的关键点在于用input_from表达依赖关系靠“所有输入节点已执行”来判断当前节点是否可以启动。每次循环记录progressed用来识别循环依赖。_run_with_retry统一处理重试重试次数来自 workflow 节点的max_retries配置。5.4 模型客户端调用 LLM 生成工作流这一步模拟“模型自己写 workflow”。它接收任务描述调用 OpenAI 兼容接口要求模型返回一个符合我们结构的 JSON 字符串。# 文件路径gigacode-demo/llm_client.py import json from typing import Dict, Any from openai import OpenAI WORKFLOW_SYSTEM_PROMPT 你是一个多智能体工作流设计器。 你会收到一个任务描述需要将任务拆解为多个 Agent 节点。 每个节点必须包含: - id: 唯一标识 - agent_name: 角色名称 - description: 该节点的职责 - model: 使用的模型名 - input_from: 依赖的节点 id 列表 - output_to: 输出到的节点 id 列表 - max_retries: 最多重试次数 只输出 JSON不要输出其他解释。 .strip() class LLMClient: def __init__(self, base_url: str, api_key: str, model: str): self.client OpenAI(base_urlbase_url, api_keyapi_key) self.model model def generate_workflow(self, task: str) - Dict[str, Any]: response self.client.chat.completions.create( modelself.model, temperature0.2, messages[ {role: system, content: WORKFLOW_SYSTEM_PROMPT}, {role: user, content: task}, ], response_format{type: json_object}, ) content response.choices[0].message.content or {} return json.loads(content) def simulate_workflow(task: str) - Dict[str, Any]: 无外部 API 时的模拟函数。 实际项目里请使用 LLMClient 读取模型返回。 这里保留一个固定结构便于离线测试执行器。 return { workflow_name: date_workday_count, version: 1.0, nodes: [ { id: research, agent_name: requirement_analyst, description: 分析需求输出函数签名和边界条件, model: your-model-name, input_from: [], output_to: [write], max_retries: 0, }, { id: write, agent_name: code_writer, description: 编写工作日计算函数, model: your-model-name, input_from: [research], output_to: [write_test], max_retries: 1, }, { id: write_test, agent_name: test_writer, description: 编写单元测试, model: your-model-name, input_from: [write], output_to: [review], max_retries: 1, }, { id: review, agent_name: code_reviewer, description: 审查代码与测试, model: your-model-name, input_from: [write, write_test], output_to: [], max_retries: 1, }, ], }这里提供两个入口一个LLMClient用于真实调用一个simulate_workflow用于离线测试。原因很简单模型名和服务商随时可能变化我不建议你照抄某个模型名。5.5 主流程串联生成与执行# 文件路径gigacode-demo/main.py from runner import AgentRunner, print_workflow_result from llm_client import simulate_workflow # 离线模拟用固定的 workflow 验证执行器 workflow simulate_workflow(计算两个日期之间的工作日数量并补充测试) # 实际项目中你可以这样调用模型生成 workflow: # from llm_client import LLMClient # client LLMClient(base_urlhttps://api.example.com/v1, api_key你的key, model你的模型名) # workflow client.generate_workflow(计算两个日期之间的工作日数量并补充测试) def fake_node_action(node, inputs): 演示执行器如何调用节点。真实项目里这里应该发起一次 LLM 调用。 node_id node[id] if node_id research: return {signature: def count_workdays(start_date, end_date) - int} elif node_id write: return {code: import datetime\n# 工作日统计实现} elif node_id write_test: return {test: pytest 用例: 2024-01-01 到 2024-01-05 应有 3 个工作日} elif node_id review: return {review: 通过} return {ok: True} def main(): runner AgentRunner(node_actionfake_node_action) result runner.execute(workflow) print_workflow_result(result) if __name__ __main__: main()运行方式python main.py这段主流程验证了整条链路模型生成 workflow执行器按依赖顺序跑完所有节点最后输出每个节点的结果。真实的项目中fake_node_action应该替换为真实 LLM 调用并传入对应节点的系统提示词。6. 运行结果与效果验证你运行python main.py后预期会看到类似这样的输出。{ research: { signature: def count_workdays(start_date, end_date) - int }, write: { code: import datetime\n# 工作日统计实现 }, write_test: { test: pytest 用例: 2024-01-01 到 2024-01-05 应有 3 个工作日 }, review: { review: 通过 } }如何判断这次运行是成功的看两点节点执行顺序满足依赖关系research 先执行write_test 后于 write 执行review 是最后一个执行的节点。输出的 key 和节点 id 一一对应。如果失败第一步应该看什么先看是否抛出了WorkflowError。如果报 “存在无法执行的节点或循环依赖”说明你生成的 workflow 里依赖关系不正确需要把节点之间的input_from和output_to打印出来人工核对。如果报 “执行轮次超过上限”说明存在循环引用例如 review 又把结果输出给了 writewrite 再输出给 review形成死循环。还有一个典型的验证方式故意把fake_node_action改成抛异常然后观察执行器是否按照max_retries重试。重试逻辑是多 Agent 工作流里最容易出 bug 的部分值得单独测试。7. 模型切换、上下文与容量真实使用中的常见问题模型自写工作流看起来省掉了配置成本但真正跑起来依然会遇到模型服务层面的问题。近期社区里集中出现了不少这类讨论。我把常见的问题整理成一张排查表。问题现象可能原因排查方式解决方案报错 model is not supported / 模型名不被识别服务商模型列表已更新workflow 里写死的模型名已下线查看服务商最新模型列表把模型名抽成配置项运行前校验可用模型列表selected model is at capacity提示换模型模型服务端负载过高当前模型不可用查看服务商状态页在运行器层实现多模型回退同一节点配置备用模型context window 超限最大长度 1048576 tokens 仍不够Agent 之间传递了完整代码或完整历史累计超过窗口打印每个节点输入和输出 token 统计每个节点只输出摘要或结构化结果不要传递全文config.toml 无法加载对话串无法继续本地配置文件格式错误或模型参数写错用配置解析器单独校验文件配置结构体校验设置默认值兜底GGUF 模型报错但系统没有可执行 runtime本地方案需要 llama.cpp runtime但环境里未安装 llama-server检查 runtime 是否存在which llama-server在环境准备阶段增加 runtime 检查缺失时自动提示安装agent terminated due to error子任务失败且没有重试策略查看工作流日志中节点执行失败原因为关键节点配置 max_retries并增加人工审批节点workflow 执行结果和预期差异大模型生成的 workflow 节点职责划分不合理打印 workflow 定义检查节点描述是否具体在系统提示词中强调“职责唯一、边界清晰”并做结构化校验本地 API 代理连接失败本地代理配置或端点路径错误检查本地代理配置和端点格式去掉不可靠的代理层直接使用服务商官方端点这里我想单独强调一个工程判断模型自写 workflow 并没有消除底层模型服务的不可靠性它只是把这些不可靠性变成了运行器可以感知、可以重试、可以反馈给模型重新生成的问题。因此你的运行器设计里一定要有错误反馈环路否则模型生成一次 workflow 后就撒手不管它的价值就折损了一半。另外不要在 workflow 的每个节点里都用同一个模型。不同职责的节点对模型能力要求不同。需求分析节点可以使用成本较低的模型代码审查节点可以使用能力更强的模型。这个策略也应该写进 workflow 的生成提示词里让模型在拆解任务时自动考虑成本和效果的平衡。8. 最佳实践与工程建议把模型自写工作流真正用进项目需要守住几条工程底线。8.1 先定义严格 Schema模型生成 workflow 时最大的风险是输出结构不合法。所以第一道防线是 JSON Schema 校验。workflow 定义中的每个字段都要有明确的类型、是否必填、取值范围。校验应该在运行时前置完成不要等到节点执行到一半才发现缺少字段。建议用 Pydantic 或 JSON Schema 库做统一校验。校验失败时把错误信息拼接进提示词让模型重新生成。这样可以显著提高成功率。8.2 显式声明依赖避免循环依赖Graph 中如果有循环执行器必须能识别并中断。我的建议是在 workflow 中只允许用max_retries表达有限的返工循环而不要在节点依赖关系上做任意环。这样可以保证 workflow 整体是一个可收敛的图而不是一个理论上可能无限执行的图。8.3 上下文管理每阶段只传摘要多 Agent 协作最大的隐性成本是 token 消耗。每个节点都把上游输出原样往下传很快会把上下文窗口打满。正确的做法是每个节点输出结构化摘要下游节点按需读取。比如 Writer 节点输出代码文件路径和函数签名而不是把整个文件内容塞进上下文。8.4 幂等与断点恢复生产环境里workflow 可能执行到一半失败。如果你不想从头再来就要给每个节点设计幂等性同一个输入反复执行结果一致且无副作用。然后把中间结果持久化失败后从断点恢复。这个原则和数据库事务很像。8.5 安全边界与最小权限模型生成的 workflow 是“动态产物”不代表它值得信任。尤其是涉及执行代码、访问数据库、修改文件的节点必须套两层约束执行环境使用沙箱或最小权限容器禁止默认 root 执行。关键操作前增加人工审批节点审批通过才能继续。任何涉及删除、覆盖、生产环境变更的操作都必须先在小范围或测试环境验证。8.6 可观测性没有日志的 workflow 等于没有。每个节点的执行耗时、token 消耗、输入输出摘要、重试次数都要记录。一个可运行的 workflow 只是起点一个可排查的 workflow 才是生产级。日志格式建议统一为 JSON方便后续接入监控平台。8.7 团队协作模板先行模型自写 workflow 不意味着完全不需要模板。对于团队的常见任务应该沉淀一批高质量 workflow 模板模型生成结果时以模板为底再按任务微调。这样既保留灵活性又避免模型每次从零拆解带来不稳定性。9. 总结与后续学习方向Gigacode 提出的“模型自己写 multi-agent workflow然后运行它”真正值得关注的不是自动化本身而是它把工作流从一个静态配置变成一个动态产物。人去写工作流模型去执行这只是第一阶段模型去生成工作流人去验收和兜底这是第二阶段。Gigacode 是第二阶段的一个有代表性的尝试。从本文的最小示例里你应该已经把三个关键点理解透了workflow 的本质是带依赖关系的图模型生成 workflow 的要点是严格约束输出结构运行器必须能感知错误并重试。这三个点合起来就是一套不依赖特定平台的 Agent 编排思路。如果你想继续深入我建议按下面顺序实践先跑通本文的离线示例熟悉执行器的拓扑调度和重试逻辑。再把fake_node_action替换为真实 LLM 调用用最简单的两个节点体验模型生成工作流的闭环。接着看 LangGraph 或 Dify 这类成熟框架对比它们的设计和模型自写工作流的差异。最后回到你自己的项目找一个高频重复的编码任务尝试用模板加模型生成的方式落地。在真正动手之前有一条建议值得记住不要迷信“模型全自动生成”的叙事。模型生成工作流时的结构化输出能力决定了它的上限而你的 Schema 校验、错误反馈和人工审批机制决定了它能不能安全落地。工具再聪明工程底线仍然要由人来守。建议先把这篇文章收藏起来等你要设计自己的 Agent 编排器时再对照着把执行器、上下文管理和重试策略一点一点补全。