1. 从 CrewAI 审批卡住说起Key 注入必须发生在审批前你给 CrewAI 的 Task 打开human_inputTrue后终端停在Human input required审批通过后下一次 Agent 调用却返回 401在给 CrewAI 设置 LLM API Key 时直接去 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_approval_intro拿 KeyBase URL 填 https://taotoken.net/api。本文从高风险多 Agent 流程设计者视角把人工确认开关与 Key 注入时序一次讲清。CrewAI 这两年在多 Agent 圈子的热度很高但真正把多 Agent 放进高风险业务的人关注点早就不是“能不能跑通”而是“哪一步会失控”。普通 Demo 里Agent 调研、写稿、总结中间出一两个幻觉大不了重跑。可一旦流程里出现外部副作用比如发通知、生成工单、触发付款、写审计日志问题就完全不一样了。你需要的不是更多 Agent而是审批门。人工确认开关的价值就在这里Agent 完成当前 Task 后不直接往下传而是暂停把产出交给人类看人类确认后下一环才继续。可很多教程只告诉你human_inputTrue却不告诉你 Key 到底该在哪一步注入。结果就是审批前调用正常审批后重新创建 LLM 客户端环境变量没读到直接 401或者 Agent 上下文被重新初始化前面调研的证据链全丢下游又开始“失忆”。本文用一套可复现的配置把 CrewAI 的人工审批 Task 拆成三个阶段审批前、审批中、审批后。核心结论先给出来Key 必须在审批前注入到 LLM 实例并且在审批后复用同一个 LLM 实例不要重新初始化。下面从 TaoToken 取 Key 开始到 CrewAI Agent/Task 配置再到 Flows 风格的审批门和排障清单全部给出可复制代码。2. TaoToken Key 与 Base URLCrewAI 的 LLM 入口怎么配先处理最容易出错的一步CrewAI 底层通过 litellm 兼容 OpenAI 风格的接口所以你需要三样东西一个可用的 API Key一个 OpenAI 兼容的 Base URL一个模型 ID。TaoToken 的 Key 在控制台创建入口是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_api_keys 。创建后复制到本地不要直接硬编码进 Git 仓库。Base URL 固定填https://taotoken.net/api注意这个 Base URL 不需要加 UTM也不要自作主张补/v1。先看环境变量写法# .env TAOTOKEN_API_KEYYOUR_API_KEY TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_MODELopenai/gpt-4o如果你习惯让 CrewAI 读取 OpenAI 兼容变量也可以这样export OPENAI_API_KEYYOUR_API_KEY export OPENAI_API_BASEhttps://taotoken.net/api export OPENAI_MODEL_NAMEopenai/gpt-4o但更推荐在代码里显式创建LLM对象因为审批流最容易出问题的点就是“审批后重新创建客户端”。显式创建可以让你清楚知道 Key 是在哪一行被注入的import os from crewai import LLM taotoken_llm LLM( modelos.getenv(TAOTOKEN_MODEL, openai/gpt-4o), base_urlhttps://taotoken.net/api, api_keyos.getenv(TAOTOKEN_API_KEY, YOUR_API_KEY), temperature0.2, )把这段代码放在所有 Agent 创建之前。也就是说进程启动后第一件事是加载环境变量并创建 LLM 实例而不是等到审批通过后才去读 Key。你可以先用一个最小调用验证 Key 和 Base URL 是否可用from crewai import LLM llm LLM( modelopenai/gpt-4o, base_urlhttps://taotoken.net/api, api_keyYOUR_API_KEY, ) resp llm.call(messages[{role: user, content: 只回复taotoken ok}]) print(resp)如果这里报 401先检查 Key 是否复制完整、是否有多余空格、是否把https://taotoken.net/api写成了带路径的地址。如果报模型不存在去 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_key_setup确认当前账号可用的模型 ID再替换TAOTOKEN_MODEL。不要在 Agent 代码里写死一个未经核实的模型名。3. 人工确认开关Task 级human_input与硬审批门CrewAI 的 Task 支持human_inputTrue这是最直接的人工确认开关。它的行为是当前 Task 执行完成后终端提示需要人工输入你输入的内容会作为该 Task 的输出反馈然后流程继续。很多人只写human_inputTrue但没设计“拒绝后怎么办”。在低风险场景里人工输入“继续”就够了。在高风险流程里你必须区分“收集意见”和“强制拦截”。下面给出一个三段式 Crew调研、撰稿、审批。审批 Task 开启人工确认同时加一个 callback 做硬门。import os from crewai import Agent, Task, Crew, Process, LLM # 1. 审批前注入 Key只创建一次 LLM llm LLM( modelos.getenv(TAOTOKEN_MODEL, openai/gpt-4o), base_urlhttps://taotoken.net/api, api_keyos.getenv(TAOTOKEN_API_KEY, YOUR_API_KEY), temperature0.2, ) researcher Agent( role资深行业研究员, goal收集可验证的公开资料输出带来源链接的要点清单, backstory你长期做竞品与行业调研习惯保留原始链接、日期和上下文。, llmllm, verboseTrue, ) writer Agent( role技术专栏作者, goal基于调研证据写出一篇结构清晰的中文技术分析, backstory你写过多年代码博客拒绝没有来源的结论。, llmllm, verboseTrue, ) reviewer Agent( role高风险流程审核员, goal检查事实、引用和逻辑漏洞给出是否放行的明确结论, backstory你负责高风险流程审核任何未经验证的数据都不允许进入下游。, llmllm, verboseTrue, ) research_task Task( description调研 CrewAI 的人工审批能力列出 5 条可验证结论每条附来源。, expected_output5 条要点每条包含来源链接和一句话摘要。, agentresearcher, ) write_task Task( description根据调研结果写一篇 800 字技术说明说明 human_input 的触发点和风险。, expected_output800 字 Markdown包含代码片段和注意事项。, agentwriter, context[research_task], ) def approval_callback(output): print(\n 待审批输出 ) print(output) decision input(\n输入 approve 放行输入其他值打回).strip().lower() if decision ! approve: raise ValueError(人工审批未通过流程中止避免错误继续向下游传导) approval_task Task( description审核上一篇技术说明的事实与引用输出 approve 或 reject 及理由。, expected_output明确结论approve/reject以及三条理由。, agentreviewer, context[write_task], human_inputTrue, # 原生人工确认任务完成后暂停 callbackapproval_callback # 硬门不通过直接抛异常阻止后续任务 ) crew Crew( agents[researcher, writer, reviewer], tasks[research_task, write_task, approval_task], processProcess.sequential, verboseTrue, ) if __name__ __main__: result crew.kickoff() print(\n最终结果\n, result)这里有两个关键点。第一human_inputTrue负责暂停和收集人工意见。它适合“我需要看一眼然后补充意见”的场景。第二callback负责强制拦截。如果人工输入不是approve直接抛异常整个 Crew 停止。这样就不会出现“人工明明点了拒绝下游 Agent 还继续基于错误结果执行”的情况。如果你使用 CrewAI Flows可以用事件驱动的方式设计审批门。核心思路是一个节点产出结果下一个节点读取状态并等待人工输入路由节点根据人工输入决定去“放行”还是“打回”。下面是一个不依赖具体版本细节的简化写法重点看数据流from crewai.flow.flow import Flow, start, listen, router class ApprovalFlow(Flow): start() def prepare_report(self): # 这里可以调用前面的 Crew产出报告草稿 return {report: 报告草稿内容, approved: None} listen(prepare_report) def human_gate(self, state): print(state[report]) answer input(输入 approve 放行输入 reject 打回).strip().lower() state[approved] (answer approve) return state router(human_gate) def route_after_approval(self, state): if state[approved]: return publish return revise listen(publish) def publish(self, state): return 审批通过继续执行外部动作 listen(revise) def revise(self, state): raise ValueError(审批未通过流程回到修订或直接终止) if __name__ __main__: flow ApprovalFlow() flow.kickoff()如果你的 CrewAI 版本对router的参数或返回写法有差异以你本地安装版本为准。但设计原则不变审批门必须能阻断错误向下游传播而不是只打印一句“请确认”。4. 时序拆解审批前、审批中、审批后的 Key 与上下文现在把 Key 注入和人工审批放在同一条时间线上。下面是一张文字版时序图便于你在团队内评审高风险流程启动进程 │ ├─ 1. 加载 .env / 环境变量TAOTOKEN_API_KEY ├─ 2. 创建 LLM(base_urlhttps://taotoken.net/api, api_keyYOUR_API_KEY) ├─ 3. 创建 Agent(researcher/writer/reviewer)全部注入同一个 llm ├─ 4. 定义 Taskapproval_task.human_inputTrue并挂 callback 硬门 ├─ 5. crew.kickoff() │ │ │ ├─ 调研 Task 调用 TaoToken → 返回调研结果 │ ├─ 撰稿 Task 调用 TaoToken → 返回文稿草稿 │ ├─ 审批 Task 完成 → human_input 暂停等待终端输入 │ │ ├─ 输入 approve → 继续下一个 Task复用同一个 llm │ │ └─ 输入其他值 → callback 抛异常流程终止 │ └─ 后续 Task 继续调用 TaoToken └─ 输出最终结果为什么强调“复用同一个 llm”因为审批是一个暂停点不是初始化点。很多线上事故是这样发生的开发者在审批前用环境变量创建了 LLM一切正常审批通过后代码进入下一个 Task为了“隔离风险”重新创建了一个 LLM重新创建时容器环境变量丢失、子进程未继承、或者.env只在启动脚本里 source 过于是下一个 Agent 调用直接 401或者虽然调用成功但模型不知道前面审批的上下文开始重新编造。正确的做法是Key 在进程启动阶段注入LLM 实例在审批前创建审批后复用。如果你确实需要为审批后的任务切换不同模型也应该显式传入同一个 Key 来源而不是依赖隐式环境变量。另一个细节是上下文交接。人工审批时不要只让审批者看一句“是否通过”。把上游 Task 的产出、证据链、工具调用记录一起展示出来。CrewAI 的 Task 支持context你可以让审批 Task 依赖前面的调研和撰稿任务这样审批者看到的是完整材料而不是孤立结论。在高风险多 Agent 流程里建议把人工审批节点放在这些位置调研完成后确认数据来源可靠避免错误事实进入写稿环节写稿完成后确认逻辑、合规、引用没有问题外部副作用前发送通知、创建工单、调用支付、执行命令之前必须有人确认最终交付前确认输出不会泄露敏感信息或者不会触发合规风险。不要把审批节点放在所有事情做完之后。那时候错误已经沿着流水线传导放大你审批的只是一份“看起来完整、事实全错”的报告。5. 高风险多 Agent 流水线审批节点、断点恢复与错误拦截从高风险流程设计者的角度看CrewAI 的human_inputTrue只是一个开关真正决定系统安全的是你如何设计错误拦截。多 Agent 系统最可怕的不是某个 Agent 出错而是错误会沿着交接链路向下传导。上游 Agent 给出一个错误数字下游 Agent 基于这个数字写分析再下游 Agent 基于分析生成结论最后输出一份逻辑自洽但事实错误的报告。人工审批节点应该承担三个职责第一检查事实来源。审批者要能看到原始链接、抓取时间、数据口径。如果 Agent 只输出“根据公开资料”这不算证据。好的expected_output应该要求每条结论附带来源。第二检查交接材料。CrewAI 的 Task 之间通过context传递结果但默认可能只传最终输出。你可以在 Task 描述里强制要求交接内容必须包含过程材料、工具调用摘要、未解决问题列表。不要让下一个 Agent 只拿到一句结论。第三决定是否放行。审批不通过时应该触发打回重跑而不是继续。前面的callback抛异常是一种简单做法。更完整的做法是把审批结果写回状态由 Flows 路由到“修订节点”或“终止节点”。如果你使用 LangGraph 这类底层图编排框架也可以实现更细粒度的检查点。但无论用什么框架原则都是不可逆动作之前必须有人工确认。断点恢复也是高风险流程的刚需。多 Agent 长任务跑到一半可能中断如果没有持久化重新跑一遍会消耗大量 Token而且可能得到不同结果。CrewAI 的 Flows 自带状态持久化和断点续跑能力适合把审批状态、任务输出、人工意见保存下来。Crew 模式更偏自主协作适合探索型任务但在强审计场景下建议用 Flows 锁住流程。这里还要提醒一个边界不要让 Agent 直接连接生产数据库。CrewAI 可以调用工具但工具应该由你在受控环境里执行。比如让 Agent 生成 SQL 草案和影响评估人工审批后由你在本地或跳板机执行 SQL。不要把 Oracle、MySQL、PostgreSQL 的生产连接串塞进 Agent 的工具里。一旦 Agent 判断跑偏它可能直接执行危险语句。审批门只能挡住流程挡不住已经交给 Agent 的过高权限。6. 排障清单CrewAI TaoToken 常见报错与修复报错一审批前正常审批后 401。原因通常是审批后重新创建了 LLM 实例但环境变量没有重新加载。修复方式把LLM创建放到进程启动阶段审批后复用同一个实例。检查代码里有没有在callback或后续 Task 里再次调用LLM(...)。报错二Human input required出现后输入内容没有生效。检查 Task 是否设置了human_inputTrue以及 Crew 的process是否为sequential或hierarchical。如果你用的是自定义流程确认人工输入被正确写回状态。输入approve后如果下游仍然使用旧输出检查context是否正确指向了审批 Task。报错三模型返回 404 或“模型不存在”。先确认 Base URL 是https://taotoken.net/api不要多加/v1。然后去 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_troubleshoot核对模型 ID。把TAOTOKEN_MODEL换成控制台里实际可用的模型。不要凭记忆填一个不存在的模型名。报错四Agent 输出质量差审批时发现全是幻觉。先检查role、goal、backstory是否写得太泛。只写“助手”两个字Agent 行为会非常不稳定。把角色写具体行业、年限、关注指标、输出偏好。其次检查expected_output是否模糊。把“调研报告”改成“5 条要点每条附带来源链接和发布日期”。验收标准越清晰Agent 越不容易敷衍。报错五Token 成本失控。多 Agent 流程的 Token 消耗远高于单轮对话。人工审批节点可以减少无效下游调用如果审批不通过直接终止不要继续跑完整个 Crew。另外审批时尽量只让审批者看关键差异不要把全部中间日志都塞进上下文。报错六审批通过后上下文丢失。不要重新创建 Agent。Agent 持有角色设定和 LLM 实例重新创建会导致上下文断裂。正确做法是让审批 Task 的产出通过context传给下游 Task。如果你必须跨进程恢复把状态持久化到外部存储再在恢复时重新注入同一个 Key 来源。7. 顺带用 Claude Code / Codex 调试 CrewAI 时的 Key 配置如果你在本地用 Claude Code 或 Codex 辅助调试 CrewAI 项目Key 和 Base URL 也可以统一走 TaoToken。注意配置格式不要混用。Claude Code 使用settings.json环境变量使用ANTHROPIC_*{ env: { ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_BASE_URL: https://taotoken.net/api } }Codex 使用config.toml不要套用ANTHROPIC_*model gpt-5 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEYCC Switch 这类工具可以理解为“三件套”供应商名称、Base URL、API Key。供应商填自定义或 OpenAI 兼容Base URL 填https://taotoken.net/apiKey 填YOUR_API_KEY。切换后先跑一个最小请求验证再启动 CrewAI避免把配置问题误判成 Agent 逻辑问题。8. 文末 CTA从模型对话到 Coding Plan再到 API Key 与 Claude Code 文档如果你还没创建 Key建议按这个顺序走一遍先开模型对话确认 TaoToken 的模型调用符合预期https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_chat如果准备长期跑 CrewAI、Claude Code、Codex 这类编码和 Agent 任务看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_coding_plan创建正式 API Key填到 CrewAI 的TAOTOKEN_API_KEYhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_api_keys如果你同时用 Claude Code 调试参考 Claude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_claude_code_doc最后再强调一次本文的核心CrewAI 的人工确认开关不是简单的human_inputTrue而是一套审批门设计TaoToken 的 Key 必须在审批前注入到 LLM 实例审批后复用同一个实例。这样既能避免审批后 401也能避免多 Agent 长任务在关键节点“失忆”跑偏。对高风险流程来说审批门是刹车Key 注入时序是油路。刹车和油路都对了多 Agent 流程才敢往生产环境走。
人工确认开关给 CrewAI，TaoToken 的 Key 放审批前
1. 从 CrewAI 审批卡住说起Key 注入必须发生在审批前你给 CrewAI 的 Task 打开human_inputTrue后终端停在Human input required审批通过后下一次 Agent 调用却返回 401在给 CrewAI 设置 LLM API Key 时直接去 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_approval_intro拿 KeyBase URL 填 https://taotoken.net/api。本文从高风险多 Agent 流程设计者视角把人工确认开关与 Key 注入时序一次讲清。CrewAI 这两年在多 Agent 圈子的热度很高但真正把多 Agent 放进高风险业务的人关注点早就不是“能不能跑通”而是“哪一步会失控”。普通 Demo 里Agent 调研、写稿、总结中间出一两个幻觉大不了重跑。可一旦流程里出现外部副作用比如发通知、生成工单、触发付款、写审计日志问题就完全不一样了。你需要的不是更多 Agent而是审批门。人工确认开关的价值就在这里Agent 完成当前 Task 后不直接往下传而是暂停把产出交给人类看人类确认后下一环才继续。可很多教程只告诉你human_inputTrue却不告诉你 Key 到底该在哪一步注入。结果就是审批前调用正常审批后重新创建 LLM 客户端环境变量没读到直接 401或者 Agent 上下文被重新初始化前面调研的证据链全丢下游又开始“失忆”。本文用一套可复现的配置把 CrewAI 的人工审批 Task 拆成三个阶段审批前、审批中、审批后。核心结论先给出来Key 必须在审批前注入到 LLM 实例并且在审批后复用同一个 LLM 实例不要重新初始化。下面从 TaoToken 取 Key 开始到 CrewAI Agent/Task 配置再到 Flows 风格的审批门和排障清单全部给出可复制代码。2. TaoToken Key 与 Base URLCrewAI 的 LLM 入口怎么配先处理最容易出错的一步CrewAI 底层通过 litellm 兼容 OpenAI 风格的接口所以你需要三样东西一个可用的 API Key一个 OpenAI 兼容的 Base URL一个模型 ID。TaoToken 的 Key 在控制台创建入口是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_api_keys 。创建后复制到本地不要直接硬编码进 Git 仓库。Base URL 固定填https://taotoken.net/api注意这个 Base URL 不需要加 UTM也不要自作主张补/v1。先看环境变量写法# .env TAOTOKEN_API_KEYYOUR_API_KEY TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_MODELopenai/gpt-4o如果你习惯让 CrewAI 读取 OpenAI 兼容变量也可以这样export OPENAI_API_KEYYOUR_API_KEY export OPENAI_API_BASEhttps://taotoken.net/api export OPENAI_MODEL_NAMEopenai/gpt-4o但更推荐在代码里显式创建LLM对象因为审批流最容易出问题的点就是“审批后重新创建客户端”。显式创建可以让你清楚知道 Key 是在哪一行被注入的import os from crewai import LLM taotoken_llm LLM( modelos.getenv(TAOTOKEN_MODEL, openai/gpt-4o), base_urlhttps://taotoken.net/api, api_keyos.getenv(TAOTOKEN_API_KEY, YOUR_API_KEY), temperature0.2, )把这段代码放在所有 Agent 创建之前。也就是说进程启动后第一件事是加载环境变量并创建 LLM 实例而不是等到审批通过后才去读 Key。你可以先用一个最小调用验证 Key 和 Base URL 是否可用from crewai import LLM llm LLM( modelopenai/gpt-4o, base_urlhttps://taotoken.net/api, api_keyYOUR_API_KEY, ) resp llm.call(messages[{role: user, content: 只回复taotoken ok}]) print(resp)如果这里报 401先检查 Key 是否复制完整、是否有多余空格、是否把https://taotoken.net/api写成了带路径的地址。如果报模型不存在去 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_key_setup确认当前账号可用的模型 ID再替换TAOTOKEN_MODEL。不要在 Agent 代码里写死一个未经核实的模型名。3. 人工确认开关Task 级human_input与硬审批门CrewAI 的 Task 支持human_inputTrue这是最直接的人工确认开关。它的行为是当前 Task 执行完成后终端提示需要人工输入你输入的内容会作为该 Task 的输出反馈然后流程继续。很多人只写human_inputTrue但没设计“拒绝后怎么办”。在低风险场景里人工输入“继续”就够了。在高风险流程里你必须区分“收集意见”和“强制拦截”。下面给出一个三段式 Crew调研、撰稿、审批。审批 Task 开启人工确认同时加一个 callback 做硬门。import os from crewai import Agent, Task, Crew, Process, LLM # 1. 审批前注入 Key只创建一次 LLM llm LLM( modelos.getenv(TAOTOKEN_MODEL, openai/gpt-4o), base_urlhttps://taotoken.net/api, api_keyos.getenv(TAOTOKEN_API_KEY, YOUR_API_KEY), temperature0.2, ) researcher Agent( role资深行业研究员, goal收集可验证的公开资料输出带来源链接的要点清单, backstory你长期做竞品与行业调研习惯保留原始链接、日期和上下文。, llmllm, verboseTrue, ) writer Agent( role技术专栏作者, goal基于调研证据写出一篇结构清晰的中文技术分析, backstory你写过多年代码博客拒绝没有来源的结论。, llmllm, verboseTrue, ) reviewer Agent( role高风险流程审核员, goal检查事实、引用和逻辑漏洞给出是否放行的明确结论, backstory你负责高风险流程审核任何未经验证的数据都不允许进入下游。, llmllm, verboseTrue, ) research_task Task( description调研 CrewAI 的人工审批能力列出 5 条可验证结论每条附来源。, expected_output5 条要点每条包含来源链接和一句话摘要。, agentresearcher, ) write_task Task( description根据调研结果写一篇 800 字技术说明说明 human_input 的触发点和风险。, expected_output800 字 Markdown包含代码片段和注意事项。, agentwriter, context[research_task], ) def approval_callback(output): print(\n 待审批输出 ) print(output) decision input(\n输入 approve 放行输入其他值打回).strip().lower() if decision ! approve: raise ValueError(人工审批未通过流程中止避免错误继续向下游传导) approval_task Task( description审核上一篇技术说明的事实与引用输出 approve 或 reject 及理由。, expected_output明确结论approve/reject以及三条理由。, agentreviewer, context[write_task], human_inputTrue, # 原生人工确认任务完成后暂停 callbackapproval_callback # 硬门不通过直接抛异常阻止后续任务 ) crew Crew( agents[researcher, writer, reviewer], tasks[research_task, write_task, approval_task], processProcess.sequential, verboseTrue, ) if __name__ __main__: result crew.kickoff() print(\n最终结果\n, result)这里有两个关键点。第一human_inputTrue负责暂停和收集人工意见。它适合“我需要看一眼然后补充意见”的场景。第二callback负责强制拦截。如果人工输入不是approve直接抛异常整个 Crew 停止。这样就不会出现“人工明明点了拒绝下游 Agent 还继续基于错误结果执行”的情况。如果你使用 CrewAI Flows可以用事件驱动的方式设计审批门。核心思路是一个节点产出结果下一个节点读取状态并等待人工输入路由节点根据人工输入决定去“放行”还是“打回”。下面是一个不依赖具体版本细节的简化写法重点看数据流from crewai.flow.flow import Flow, start, listen, router class ApprovalFlow(Flow): start() def prepare_report(self): # 这里可以调用前面的 Crew产出报告草稿 return {report: 报告草稿内容, approved: None} listen(prepare_report) def human_gate(self, state): print(state[report]) answer input(输入 approve 放行输入 reject 打回).strip().lower() state[approved] (answer approve) return state router(human_gate) def route_after_approval(self, state): if state[approved]: return publish return revise listen(publish) def publish(self, state): return 审批通过继续执行外部动作 listen(revise) def revise(self, state): raise ValueError(审批未通过流程回到修订或直接终止) if __name__ __main__: flow ApprovalFlow() flow.kickoff()如果你的 CrewAI 版本对router的参数或返回写法有差异以你本地安装版本为准。但设计原则不变审批门必须能阻断错误向下游传播而不是只打印一句“请确认”。4. 时序拆解审批前、审批中、审批后的 Key 与上下文现在把 Key 注入和人工审批放在同一条时间线上。下面是一张文字版时序图便于你在团队内评审高风险流程启动进程 │ ├─ 1. 加载 .env / 环境变量TAOTOKEN_API_KEY ├─ 2. 创建 LLM(base_urlhttps://taotoken.net/api, api_keyYOUR_API_KEY) ├─ 3. 创建 Agent(researcher/writer/reviewer)全部注入同一个 llm ├─ 4. 定义 Taskapproval_task.human_inputTrue并挂 callback 硬门 ├─ 5. crew.kickoff() │ │ │ ├─ 调研 Task 调用 TaoToken → 返回调研结果 │ ├─ 撰稿 Task 调用 TaoToken → 返回文稿草稿 │ ├─ 审批 Task 完成 → human_input 暂停等待终端输入 │ │ ├─ 输入 approve → 继续下一个 Task复用同一个 llm │ │ └─ 输入其他值 → callback 抛异常流程终止 │ └─ 后续 Task 继续调用 TaoToken └─ 输出最终结果为什么强调“复用同一个 llm”因为审批是一个暂停点不是初始化点。很多线上事故是这样发生的开发者在审批前用环境变量创建了 LLM一切正常审批通过后代码进入下一个 Task为了“隔离风险”重新创建了一个 LLM重新创建时容器环境变量丢失、子进程未继承、或者.env只在启动脚本里 source 过于是下一个 Agent 调用直接 401或者虽然调用成功但模型不知道前面审批的上下文开始重新编造。正确的做法是Key 在进程启动阶段注入LLM 实例在审批前创建审批后复用。如果你确实需要为审批后的任务切换不同模型也应该显式传入同一个 Key 来源而不是依赖隐式环境变量。另一个细节是上下文交接。人工审批时不要只让审批者看一句“是否通过”。把上游 Task 的产出、证据链、工具调用记录一起展示出来。CrewAI 的 Task 支持context你可以让审批 Task 依赖前面的调研和撰稿任务这样审批者看到的是完整材料而不是孤立结论。在高风险多 Agent 流程里建议把人工审批节点放在这些位置调研完成后确认数据来源可靠避免错误事实进入写稿环节写稿完成后确认逻辑、合规、引用没有问题外部副作用前发送通知、创建工单、调用支付、执行命令之前必须有人确认最终交付前确认输出不会泄露敏感信息或者不会触发合规风险。不要把审批节点放在所有事情做完之后。那时候错误已经沿着流水线传导放大你审批的只是一份“看起来完整、事实全错”的报告。5. 高风险多 Agent 流水线审批节点、断点恢复与错误拦截从高风险流程设计者的角度看CrewAI 的human_inputTrue只是一个开关真正决定系统安全的是你如何设计错误拦截。多 Agent 系统最可怕的不是某个 Agent 出错而是错误会沿着交接链路向下传导。上游 Agent 给出一个错误数字下游 Agent 基于这个数字写分析再下游 Agent 基于分析生成结论最后输出一份逻辑自洽但事实错误的报告。人工审批节点应该承担三个职责第一检查事实来源。审批者要能看到原始链接、抓取时间、数据口径。如果 Agent 只输出“根据公开资料”这不算证据。好的expected_output应该要求每条结论附带来源。第二检查交接材料。CrewAI 的 Task 之间通过context传递结果但默认可能只传最终输出。你可以在 Task 描述里强制要求交接内容必须包含过程材料、工具调用摘要、未解决问题列表。不要让下一个 Agent 只拿到一句结论。第三决定是否放行。审批不通过时应该触发打回重跑而不是继续。前面的callback抛异常是一种简单做法。更完整的做法是把审批结果写回状态由 Flows 路由到“修订节点”或“终止节点”。如果你使用 LangGraph 这类底层图编排框架也可以实现更细粒度的检查点。但无论用什么框架原则都是不可逆动作之前必须有人工确认。断点恢复也是高风险流程的刚需。多 Agent 长任务跑到一半可能中断如果没有持久化重新跑一遍会消耗大量 Token而且可能得到不同结果。CrewAI 的 Flows 自带状态持久化和断点续跑能力适合把审批状态、任务输出、人工意见保存下来。Crew 模式更偏自主协作适合探索型任务但在强审计场景下建议用 Flows 锁住流程。这里还要提醒一个边界不要让 Agent 直接连接生产数据库。CrewAI 可以调用工具但工具应该由你在受控环境里执行。比如让 Agent 生成 SQL 草案和影响评估人工审批后由你在本地或跳板机执行 SQL。不要把 Oracle、MySQL、PostgreSQL 的生产连接串塞进 Agent 的工具里。一旦 Agent 判断跑偏它可能直接执行危险语句。审批门只能挡住流程挡不住已经交给 Agent 的过高权限。6. 排障清单CrewAI TaoToken 常见报错与修复报错一审批前正常审批后 401。原因通常是审批后重新创建了 LLM 实例但环境变量没有重新加载。修复方式把LLM创建放到进程启动阶段审批后复用同一个实例。检查代码里有没有在callback或后续 Task 里再次调用LLM(...)。报错二Human input required出现后输入内容没有生效。检查 Task 是否设置了human_inputTrue以及 Crew 的process是否为sequential或hierarchical。如果你用的是自定义流程确认人工输入被正确写回状态。输入approve后如果下游仍然使用旧输出检查context是否正确指向了审批 Task。报错三模型返回 404 或“模型不存在”。先确认 Base URL 是https://taotoken.net/api不要多加/v1。然后去 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_troubleshoot核对模型 ID。把TAOTOKEN_MODEL换成控制台里实际可用的模型。不要凭记忆填一个不存在的模型名。报错四Agent 输出质量差审批时发现全是幻觉。先检查role、goal、backstory是否写得太泛。只写“助手”两个字Agent 行为会非常不稳定。把角色写具体行业、年限、关注指标、输出偏好。其次检查expected_output是否模糊。把“调研报告”改成“5 条要点每条附带来源链接和发布日期”。验收标准越清晰Agent 越不容易敷衍。报错五Token 成本失控。多 Agent 流程的 Token 消耗远高于单轮对话。人工审批节点可以减少无效下游调用如果审批不通过直接终止不要继续跑完整个 Crew。另外审批时尽量只让审批者看关键差异不要把全部中间日志都塞进上下文。报错六审批通过后上下文丢失。不要重新创建 Agent。Agent 持有角色设定和 LLM 实例重新创建会导致上下文断裂。正确做法是让审批 Task 的产出通过context传给下游 Task。如果你必须跨进程恢复把状态持久化到外部存储再在恢复时重新注入同一个 Key 来源。7. 顺带用 Claude Code / Codex 调试 CrewAI 时的 Key 配置如果你在本地用 Claude Code 或 Codex 辅助调试 CrewAI 项目Key 和 Base URL 也可以统一走 TaoToken。注意配置格式不要混用。Claude Code 使用settings.json环境变量使用ANTHROPIC_*{ env: { ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_BASE_URL: https://taotoken.net/api } }Codex 使用config.toml不要套用ANTHROPIC_*model gpt-5 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEYCC Switch 这类工具可以理解为“三件套”供应商名称、Base URL、API Key。供应商填自定义或 OpenAI 兼容Base URL 填https://taotoken.net/apiKey 填YOUR_API_KEY。切换后先跑一个最小请求验证再启动 CrewAI避免把配置问题误判成 Agent 逻辑问题。8. 文末 CTA从模型对话到 Coding Plan再到 API Key 与 Claude Code 文档如果你还没创建 Key建议按这个顺序走一遍先开模型对话确认 TaoToken 的模型调用符合预期https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_chat如果准备长期跑 CrewAI、Claude Code、Codex 这类编码和 Agent 任务看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_coding_plan创建正式 API Key填到 CrewAI 的TAOTOKEN_API_KEYhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_api_keys如果你同时用 Claude Code 调试参考 Claude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcrewai_claude_code_doc最后再强调一次本文的核心CrewAI 的人工确认开关不是简单的human_inputTrue而是一套审批门设计TaoToken 的 Key 必须在审批前注入到 LLM 实例审批后复用同一个实例。这样既能避免审批后 401也能避免多 Agent 长任务在关键节点“失忆”跑偏。对高风险流程来说审批门是刹车Key 注入时序是油路。刹车和油路都对了多 Agent 流程才敢往生产环境走。
