Twitter AI 智能体 - 2026-07-12¶
1. 人们在讨论什么¶
1.1 运行框架卫生取代了含糊的提示建议 🡕¶
7 月 12 日最密集的一组讨论，把智能体质量当成一种操作纪律：定义循环、精简技能列表、按通道路由模型，并在生成代码前强制先做规划。有 8 条高信号内容支撑了这一模式，其中几条进一步指出，真正的瓶颈不是再多生成一些 token，而是决定该加载什么、何时才算做完，以及哪些环节需要审查。
@MengTo 表示（122 点赞、13 回复、14,807 浏览、137 收藏），他现在会给智能体开放式目标，让 GPT-5.6 Sol 把它们拆成 20 多个具体步骤，然后把每一步都放进各自的线程里执行，这样每项改动都能独立提交、审查或回滚。这里最特别的角度，并不是抽象层面的自主性，而是把隔离当成控制机制：用一队各自聚焦的执行者，替代一个巨大的上下文窗口；回复里也补充了一条保留意见：跨步骤的耦合仍然必须被显式盯住。
@shannholmberg 展示了 三套规划系统——Superpowers、G-Stack，以及 Matt Pocock 的 grill-first skills（61 点赞、13 回复、2,570 浏览、65 收藏）——它们都把工作流的前半段固定成同一套动作：澄清、写规格、拆解、审查，然后再交付。配图之所以重要，是因为它把模糊的“先规划”规范，变成了有名字的阶段和审查闸门，而且这些做法既能复用于代码工作，也能复用于非代码工作。
@kunchenguid 绘制了 一张 firstmate 模型组织图（67 点赞、18 回复、3,409 浏览、57 收藏）：由 GPT-5.6 Sol 或 Grok 4.5 跑快速编排循环，由 Claude Fable 5 处理更深入的产品和技术设计，再用一条更便宜的 GPT-5.6 Sol 审查通道在最后兜底查错。附图的信息量很大，因为它把模型选择变成了可操作的流程：Grok 负责实时 X / 新闻任务，Codex 负责功能开发，而审查也从事后补救变成了一条专门通道。
@Voxyz_ai 认为，大型全局技能包现在反而成了负担（35 点赞、6 回复、3,305 浏览、42 收藏），因为重复的技能会迫使智能体去协调彼此冲突的指令，并额外支付上下文税负。他还提到了 autoskills；其 README 写明，这个工具会扫描项目文件，只从经过审计的注册表里选择匹配技能，用 SHA-256 哈希校验，并支持在本地写入前先试运行。
@pvncher 警告，这种纪律甚至一路延伸到了技能描述本身：如果某个技能对“如何使用子智能体”的表述过于宽泛，GPT-5.6 Sol 可能会比预期更频繁地激活它，从而烧掉额外用量（61 点赞、9 回复、9,698 浏览、72 收藏）。回复则从另一个角度强化了同一教训：降低推理等级、减少已加载技能、缩短描述，这些事情的重要性可能和模型选择本身一样高。
@RoundtableSpace 分享了 免费课程 《Learn Harness Engineering》（89 点赞、10 回复、49,996 浏览、43 收藏）；其截图展示了围绕 AGENTS.md、初始化、可观测性和交接的讲座、项目与资源库。这很重要，因为关于运行框架的讨论已经不再只是非正式建议，而是在变成公开课程体系。
讨论要点： 大家常见的回应模式，是把规则从记忆里挪到可复用工件里。操作者想要的是模型通道、技能过滤器、审查闸门和规格步骤都变成系统行为，而不是每次都得自己记着敲出的一句话。
与前日对比： 7 月 11 日的重点，是面向智能体的全仓操作系统；到 7 月 12 日，方向没有变，但讨论又下沉了一层，进入操作卫生层面：技能精简、模型通道，以及可复用的规划流程。
1.2 多智能体工作边界更清晰，也更受上下文约束 🡕¶
围绕多智能体的热情并没有消失，但高信号内容对“什么时候并行才有帮助”和“哪些地方必须保持约束”讲得具体得多。构建者反复回到同一组约束：只拆分彼此独立的工作、让每个上下文保持小巧，并用闸门或停止条件来限制成本和漂移。有 6 条内容提供了具体证据。
@shivam74689 构建了 一个基于 LangGraph 的并行多智能体股票研究系统，分别包含财务、新闻、社交情绪和 SEC 文件分支（40 点赞、2 回复、1,284 浏览、32 收藏）。他的论点说得很直白：当每个分支彼此独立、而且本来就都需要运行时，扇出 / 扇入模式比把所有事情都路由给一个总控智能体更简单也更快。截图之所以重要，是因为它同时展示了编排图和最终合并报告的成品界面。
@petergyang 总结了 Cognition 的 Jared 的观点：强大的智能体需要足够空间发挥，但前提只能是在狭窄的上下文之内（35 点赞、6 回复、9,015 浏览、27 收藏）。其中最具体的说法是，正确的拆分其实是一个经济学问题：目标是最大化回报，而不是单纯增加 token 消耗，因此每个子智能体都应该拿到边界清晰的任务和较小的上下文窗口。
@pvncher 询问了 在 GPT-5.6 中创造性使用子智能体的方法（56 点赞、11 回复、4,479 浏览、18 收藏）；价值最高的一条回复描述的是持久工作线程，带有目标锁、验收标准、心跳，以及审查或发布闸门。另一条回复则说，Claude Code 搭配 Fable 已经会自动拉起智能体团队，而 Codex 仍然需要刻意提示，才能做到类似的事。
@nyk_builderz 认为，编排器应该刻意保持便宜且“笨”，只有在某个闸门要求时，才升级到昂贵的子智能体（9 点赞、1 回复、706 浏览、11 收藏）。这让多智能体不再是展示噱头，而成了一套可计量的系统。
@gabrielchua 提到了 OpenAI 新发布的 《Responses API multi-agent guide》。文档写明，根智能体可以并行拉起并协调子智能体，但推荐使用边界清晰、彼此独立的工作流，并把 max_concurrent_subagents 的保守默认值设为 3（6 点赞、2 回复、312 浏览）。这张图很有信息量，因为它把“根智能体 + 子智能体”的模式呈现成了官方产品形态，而不再只是社区里临时拼凑的做法。
讨论要点： 最强的细节，是大家在反对“越多越好”的极大主义。人们想要的多智能体系统，得知道什么时候不该分支、什么时候该停下，以及怎样把每个分支的成本压到足够低，才能反复运行。
与前日对比： 7 月 11 日把图式规划和托管式子智能体当作方向信号；到 7 月 12 日，这些内容已经被翻译成了操作指引：扇出 / 扇入、窄上下文，以及明确的并发上限。
1.3 控制层、规格文件与付费智能体底座变得更具体 🡕¶
7 月 12 日最像产品的，不是新的通用智能体，而是围绕智能体的一组控制层：产品意图文件、由评估支撑的完工校验、供应链来源证明，以及付费服务市场。有 7 条内容支撑了这个主题。
@gokulr 宣布了 ProductSpec MCP server（20 点赞、8 回复、2,717 浏览、21 收藏）。这些新工具让编程智能体可以读取范围、验收标准、AI 评估、成功指标及配套工件，然后在宣称任务已做完前调用 check_completion_claim。公开的 ProductSpec 仓库 写明，这套标准还附带验证器、GitHub Action、智能体技能，以及 Decision Trace 支持，于是产品意图不再只是人类忘了重新打开的文档，而成了一个可查询的控制文件。
@Saanjana_Nikita 指出，生产故障通常都很“无聊”：虚假完工、无限循环、失灵的工具重试，或者上下文过载（55 点赞、43 回复、1,181 浏览）。附图之所以有信息量，是因为它直接点明了这些故障模式，并把修复方向指向评估，而不是演示。
@Azurite_ai 警告 HalluSquatting：模型先幻觉出一个包名或仓库名，攻击者抢先注册它，随后智能体就装错了东西（57 点赞、48 回复、396 浏览）。截图之所以关键，是因为它把这个危险模式展示得非常具体——安装时，系统会把一个刚创建不久的仓库直接标成可疑。
@marclou 补上了 TrustMRR 公共 API 的一个 MCP 包装器，让智能体可以按营收、MRR 和营销渠道查询创业公司（205 点赞、48 回复、42,886 浏览、90 收藏）。TrustMRR API 文档 证实，这个 API 提供经验证的创业公司营收数据，并支持按营收、MRR、要价和增长筛选，因此这是一套结构化的业务数据接口，而不是抓取网页的捷径。
@NavenNetwork 推出了 Naven Marketplace，智能体可以从 CoinGecko、CoinMarketCap 和 Nansen 等提供商那里购买付费、可验证的服务（63 点赞、14 回复、3,469 浏览）。截图之所以重要，是因为它直接展示了按调用计费的列表模式，而 x402 概览 则解释了底层支付层：这是基于 HTTP 402 的可编程稳定币支付，面向无需账号或会话的 AI 智能体。
讨论要点： 规格、安全和服务发现，都被当成同一种问题来处理：给智能体一个更窄的可信边界，然后让每一次外部动作都更容易检查。
与前日对比： 7 月 11 日已经出现了契约和 MCP 轨道；到 7 月 12 日，这些内容又进一步具体化，表现为由规格支撑的完工校验、包来源警告、经验证的营收 API，以及按调用付费的服务市场。
2. 令人困扰的问题¶
上下文膨胀与失控的用量¶
高严重度。@pvncher 警告（61 点赞、9 回复、9,698 浏览、72 收藏），冗长的技能描述和宽泛的子智能体措辞，可能在 GPT-5.6 Sol 下触发额外用量；而 @Voxyz_ai 形容（35 点赞、6 回复、3,305 浏览、42 收藏），全局 Codex 与 Claude Code 技能堆已经变成了互相冲突的规则，模型现在还得自己去协调。@RoundtableSpace 展示了（53 点赞、15 回复、43,315 浏览）一套预算护栏工作流，原因恰恰是：一个不受约束的智能体，可能在任何人察觉之前就烧掉昂贵的视频生成额度。人们现在的应对方式，是少加载技能、降低推理等级、对安装先做试运行，并在高成本动作前强制加入人工检查点。这值得投入去做成产品，因为当前的解决办法仍然是手工修剪，而不是一等工具。
智能体仍然不知道何时才算做完¶
高严重度。@Saanjana_Nikita 认为（55 点赞、43 回复、1,181 浏览），真正的生产故障是：虚假完工、无限循环、失灵的工具重试，以及上下文过载。@gokulr 构建了 ProductSpec 的 check_completion_claim 工具（20 点赞、8 回复、2,717 浏览、21 收藏），因为智能体往往看不到原始范围或验收标准；而 @nyk_builderz 表示（9 点赞、1 回复、706 浏览），反复提示“停下来先问”本质上是一条治理规则，应该属于闸门。人们现在靠审查闸门、验收标准和评估来应对。这值得投入去做成产品，因为几条彼此独立的内容都收敛到了同一个缺失原语：可复用的验证器。
模型路由依旧手工且脆弱¶
中高严重度。@kunchenguid 发布了 一整张组织图，只为了解释何时该让 Fable、GPT-5.6 Sol、Grok 4.5、Codex 和 Opus 4.8 各自接手工作（67 点赞、18 回复、3,409 浏览、57 收藏）。@bindureddy 推广了 定制的编程智能体鸡尾酒组合（139 点赞、14 回复、350,566 浏览），但最有用的一条回复指出，真正难的地方，是判断哪些代码足够新颖，值得交给昂贵模型；哪些只是样板，交给便宜模型就够了。@uday_devops 把 Claude Code 和 Cursor 定位成两种完全不同的工具形态——前者更像系统构建器，后者更像编码助手——而不是可直接替换的同类（25 点赞、20 回复、791 浏览）。人们现在的应对方式，是手工打造不同通道、回退规则，以及工具专属工作流。这值得投入去做成产品，因为路由逻辑目前大多仍是口耳相传的经验。
包与仓库来源成了智能体特有的安全缺口¶
中等严重度。@Azurite_ai 描述了 HalluSquatting：攻击者会在智能体安装之前，先抢注模型幻觉出来的包名或仓库名（57 点赞、48 回复、396 浏览）。@pengsonal 又补充了 同一个信任问题在框架侧的第二个版本：请使用官方的 FoundationAgents/OpenManus repo，因为同名的假仓库和诈骗 token 也在流通（16 点赞、11 回复、191 浏览）。人们当前的应对方式，是优先使用经过审计的注册表、固定清单，以及官方来源。这值得投入去做成产品，因为智能体式安装会放大那些本来可能被人类发现的错误。
3. 人们期望的功能¶
项目作用域的技能加载器，而不是全局技能垃圾场¶
诉求说得非常明确：只保留两类技能——模型无法自行推断的项目知识，以及团队原本容易忘掉的真实命令和检查。@Voxyz_ai 说，全局技能堆已经变成了上下文税负，而 autoskills 提供了一个部分答案：扫描技术栈、经过审计的技能包、哈希校验，以及试运行安装。这是一个实际需求，而不是情绪性诉求。人们想要的是更少的指令杂音和更少的误触发。机会评级：[+++] 直接。
编码前可供智能体查询的产品意图控制文件¶
@gokulr 把缺失的那个文件讲得很直白：要解决什么问题、哪些在范围内、哪些不在范围内、哪些验收标准必须通过、该跑哪些 AI 评估，以及上线后什么才算成功。ProductSpec MCP 是一种具体落地方案，但需求并不止于这一个项目。智能体需要一种能跨越仓库、issue、提示词和审查边界持续存在的控制文件。这很紧迫，因为它正中反复出现的“虚假完工”抱怨。机会评级：[+++] 直接。
可复用的停止条件、预算上限与人工检查点¶
人们反复要求的，是更安全的长时运行，而不是为了自主性本身再继续加码。@RoundtableSpace 在昂贵的视频生成前插入了人工检查点；@Saanjana_Nikita 说，可靠的团队相信评估，而不是演示；@nyk_builderz 则希望这些闸门只编码一次，而不是每天重敲。真正的实际需求，是一层可复用的验证器：能停下长时间运行、计量预算，并在恰当的时候升级给人类。现有工具解决了其中的一部分，但整个工作流看起来仍然很手工。机会评级：[++] 直接。
面向智能体的付费、可验证服务市场¶
@NavenNetwork 希望智能体能够按调用发现并支付给专业服务，而 @marclou 则希望用 MCP 包装业务数据 API，让智能体可以直接回答收购问题。这里的需求非常实际：智能体需要可信的外部能力，而且这些能力应该比一对一的定制集成更容易购买，也更容易检查。机会评级：[++] 直接。
超越提示技巧的公开运行框架与循环课程¶
@RoundtableSpace 和 @RohOnChain 都放大了免费的运行框架和循环资源，因为许多构建者对循环、验证器和审查闸门仍然没有共享词汇。这种需求一部分是教育性的，一部分是运营性的：团队想要的是今天下午就能拿来用的可移植模式，而不是又一门泛泛的 AI 课程。机会评级：[+] 竞争激烈。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Code | 编程运行框架 | (+) | 高自主度的多文件工作、系统指令、长上下文推理 | 原生 IDE 感较弱；需要预先设计结构和闸门 |
| Cursor | IDE 编程工具 | (+/-) | 行内编辑很快、反馈回路紧、可用侧边聊天切换上下文 | 更偏响应式而非主动式；不太适合长时间运行的编排 |
| GPT-5.6 Sol | LLM | (+) | 计划拆解强、后端与审查通道能力好，适合小线程工作 | 技能或推理档位配置不当时，用量会突然飙升 |
| Claude Fable 5 | LLM | (+) | 擅长深入的产品与技术设计、编排、对抗式审查 | 大批量开发时更慢或更贵；需要预算护栏 |
| Grok 4.5 | LLM | (+/-) | 开发通道快，并能实时访问 X 和新闻 | 在混合技术栈里，额度限制和架构分歧会变成问题 |
| LangGraph | 编排框架 | (+) | 共享状态同步下的扇出 / 扇入模式清晰 | 必须有意识地在总控智能体和并行模式之间做选择 |
| autoskills | 技能安装器与注册表 | (+) | 技术栈检测、审计注册表、试运行、哈希校验 | 只有当技能真的带来项目知识或验证价值时才值得 |
| ProductSpec MCP | 规格与控制层 | (+) | 把范围、验收标准、AI 评估和完工校验都做成工具 | 需要有纪律地维护 Product Spec |
| OpenAI Responses Multi-agent | API 运行时 | (+) | 托管式拉起子智能体、共享工具、并发可控 | 仍是测试版；会增加 token 成本；不适合共享可变状态 |
| TrustMRR API plus MCP | 数据底座 | (+) | 经验证的创业公司营收数据，以及智能体可查询的筛选能力 | 需要 API 密钥且有速率限制；业务数据领域较窄 |
| Naven Marketplace plus x402 | 智能体商业层 | (+) | 按调用定价、可验证的服务，以及机器支付 | 生态还早；信任和验证本身仍然需要投入 |
| OpenManus | 开源智能体框架 | (+/-) | 自带模型后端的通用智能体底座、CLI 和 MCP 模式，社区信号强 | 用户仍要承担模型成本，而且官方把多智能体流程标为不稳定 |
整体满意度最高的时候，通常是某个工具消除了一个具体税负，而不是承诺泛泛的自主性。@kunchenguid 和 @bindureddy 都把规划者、执行者和审查者拆给了不同模型；@pvncher 和 @Voxyz_ai 一直在试图缩小技能表面；@gokulr 则把范围和验收标准移进了控制文件；而 @marclou 与 @NavenNetwork 则用对智能体友好的 API 包装外部数据和服务。
因此，迁移压力看起来已经不再像“选出一个最好的模型”，而更像“给每条通道一个更窄的任务、更小的上下文，以及更明确的验收依据”。真正的竞争动态，发生在那些能路由工作、验证结果并控制成本的脚手架之间，而不只是模型厂商之间。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| ProductSpec MCP server | @gokulr | 让编程智能体能通过 MCP 工具查询产品意图 | 防止开发跑偏和靠不住的完工声明 | Markdown Product Specs、解析器与验证器、MCP、GitHub Action | 测试版 | tweet, repo, editor |
| TrustMRR MCP | @marclou | 为智能体封装经验证的创业数据 API | 让智能体按营收、MRR 和渠道搜索收购候选，而不是抓取网页 | 公开 API、MCP、计划中的 ChatGPT 应用 | 测试版 | tweet, docs |
| Naven Marketplace | @NavenNetwork | 面向自主智能体的付费、可验证服务市场 | 让智能体按调用结算地获取按需数据与情报端点 | x402、稳定币支付、服务端点 | 测试版 | tweet, x402 docs |
| autoskills | midudev via @Voxyz_ai | 检测项目技术栈并安装经过审计的匹配技能 | 减少全局技能蔓延和随机安装第三方技能 | Node.js CLI、审计注册表、SHA-256 清单、skills-lock.json | 已发布 | tweet, repo |
| OpenManus | FoundationAgents via @pengsonal | 带 BYO 模型后端、CLI 和 MCP 模式的开源通用智能体框架 | 给构建者一个无需排队的通用智能体底座 | Python、CLI、MCP、可选多智能体流程 | 测试版 | tweet, repo |
| Parallel Stock Research Agent | @shivam74689 | 把财务、新闻、社交和 SEC 智能体合并起来的扇出 / 扇入股票研究工作流 | 展示并行专家在哪些场景下胜过总控式调度 | LangGraph、Python、共享状态、Streamlit UI | 早期版 | tweet |
| firstmate agent distro | @kunchenguid | 跨多个运行框架、由提示词、技能和脚本组成的可复用行为层 | 给团队一套可移植的模型路由与审查配置，而不是在每个工具里重建一遍 | 系统提示词、内置技能、bash 脚本、多模型通道 | 早期版 | routing chart, agent distro thread |
ProductSpec MCP 和 autoskills 都把控制前移到了工作流更早的阶段。ProductSpec 在智能体写代码之前就把范围、验收标准和 AI 评估摆到前面，而 autoskills 则在运行开始前就决定到底允许加载哪一组技能。
TrustMRR MCP 和 Naven Marketplace 更像是底座，而不是面向终端用户的聊天体验。两者反复被提起的触发点其实相同：智能体需要结构化的外部能力，而且这些能力应该比临时浏览器操作或一次性集成更容易查询、定价和信任。
OpenManus 和 firstmate 说明，开源活力仍然分散在完整框架和架在现有运行框架之上的轻行为层之间。shivam74689 的股票研究原型再次强调了当天最重要的编排教训：只有当每个子任务都拥有自己的状态，而且合并点明确时，并行分支才真正有帮助。
6. 新动态与亮点¶
Loop Engineering 成了明确的“验证器优先”框架¶
@RohOnChain 介绍了 免费的 《Loop Engineering Guide》，它提出了一个很具体的主张：现在的瓶颈是验证器，而不是生成器。这值得注意，因为它把社交媒体上零散流传的梗，变成了一套可供检视的框架，里面包含开放循环与封闭循环、明确的停止条件，以及 Andrew Ng 的三层循环模型。
ProductSpec MCP 把产品意图变成了可调用的工具接口¶
@gokulr 发布了 ProductSpec MCP，而公开的 ProductSpec 仓库 说明，这不只是宣布一种格式。它还附带验证器、GitHub Action、智能体技能、Decision Trace 支持，以及让智能体能直接查询范围、验收标准、AI 评估和完工状态的 MCP 工具。
HalluSquatting 为“幻觉包安装”问题给出了清晰的攻击模型¶
@Azurite_ai 把 HalluSquatting 命名为这样一种利用方式：AI 智能体先幻觉出一个包名或仓库名，攻击者再去抢占这个名字。这值得注意，因为它把一个模糊的“装错东西”故事，重写成了安全工具真正可以瞄准的、可重复出现的供应链模式。
OpenAI 的 Responses API 在测试版中正式推出托管式多智能体¶
@gabrielchua 重点提到 OpenAI 的 《multi-agent Responses API guide》。这份指南把根智能体拉起子智能体、子智能体消息传递、等待机制以及并发上限都写进了文档。这很重要，因为现在的产品形态，已经对齐了许多操作者此前还在讨论串和技能里手工拼装的那套工作流。
7. 机会在哪里¶
[+++] 产品意图与完工闸门层 —— @gokulr、@Saanjana_Nikita、@nyk_builderz，以及 《Loop Engineering Guide》 都指向同一个缺失层：智能体在宣称做完之前，需要范围、验收标准，以及一套完工声明校验。这一机会很强，因为这个信号同一天既以痛点形式出现，也以实际构建形式出现。
[+++] 上下文预算与技能治理工具 —— @pvncher、@Voxyz_ai 和 @RoundtableSpace 讲的是同一种税负：无关指令太多，而成本控制太少。这一机会很强，因为节省是立刻可见的，而现有权宜方案仍然高度依赖手工操作。
[++] 混合模型团队的路由与评估器层 —— @kunchenguid、@bindureddy、@petergyang，以及 OpenAI 的 多智能体文档 都展示了手工规划、执行和审查通道。这一机会属中等，因为需求很清楚，但正确的分类逻辑仍然高度依赖具体工作负载。
[++] 智能体原生的付费服务底座 —— @marclou 和 @NavenNetwork 展示了对机器对机器商业和结构化外部数据的需求。这一机会属中等，因为信任、定价和采用需要一起成熟。
[+] 依赖来源证明与幻觉安装防御 —— @Azurite_ai 和 @pengsonal 揭示了一个狭窄但真实的安全缺口：智能体式安装器比谨慎的人类更容易被骗。这一机会正在浮现，因为利用模式已经很明显，但自动化防御的市场还很早期。
8. 要点总结¶
- 可靠的智能体工作继续向更底层下沉。 最强的讨论，不再只是围绕巧妙提示词，而是规划框架、技能精简和模型通道。(source, source)
- 验证器成了反复出现的控制面。 ProductSpec 的
check_completion_claim、循环工程指南，以及关于生产故障的讨论串，都收敛到了同一个点：真正稀缺的能力，是判断什么才算做完。(source, source) - 多智能体方案的使用更有选择性，而不是更盲目。 构建者更偏好把扇出 / 扇入用于彼此独立的任务，用廉价编排器做闸门，并给每个子智能体分配较小的上下文，而不是无限制地分支。(source, source)
- 最具体的商业化动能来自智能体底座，而不是智能体“人格”。 TrustMRR 和 Naven 都把外部能力包进了结构化、可付费的接口里，智能体可以直接调用。(source, source)
- 智能体侧的供应链信任正在成为真正的安全类别。 HalluSquatting 和 OpenManus 来源警告都说明，智能体式安装器会创造新的路径，把坏依赖偷渡进原本正常的工作流。(source, source)