一句话：把开放式聊天换成定向任务流，agent 才像审计员
GitHub 安全实验室研究员 Kevin Stubbings 公开了一套开源的 Taskflow Agent：它把提示词与工作流打包，让模型按更小、更有指向的步骤走完一次安全审计，而不是收到一句「去找 bug」就开干。靠这套方法，团队在多个开源安卓应用里发现并上报了 24 个漏洞——其中 OsmAnd 暴露位置数据、Wikipedia 安卓应用里一条深链解析缺陷与 WebView cookie 问题串成账号接管链，都已被负责任披露。
机制拆解：从入口到漏洞类的定向推进
Taskflow 的核心，是把审计拆成可复现的小步骤。它先识别移动端的攻击入口（比如导出的 activity、深链、intent），再针对该组件让模型去想这一类组件常见的漏洞类；之后多次运行，用重复跑来暴露单次容易漏掉的复杂问题。换句话说，agent 不是凭感觉漫聊，而是在一张地图里循序渐进。团队给出的实测节奏是：一个中等体量仓库大约 1 到 2 小时，且需要 Copilot 许可与高级模型请求。
为什么窄任务流胜过开放聊天
这件事的方法论价值，比 24 这个数字本身更大。过去让 agent 做安全审计，常见失败是「要么啥都报、要么报不准」——开放式提问让模型在巨大代码空间里漂移。Taskflow 把问题收窄到「这个组件、这一类漏洞」，等于给模型一个聚光灯。安全实验室还特意说明，报告里的例子此前就已披露，整套方法是给研究者做首轮针对性筛查，而不是让 agent 自己下结论。这种「窄任务 + 复现」的结构，对漏洞发现、代码审查这类需要上下文判断的活，复用性很强。
工程要点：仍要人工终审严重度
值得记的一笔是 GitHub 自己的提醒：模型会误判严重度、会报误报，研究者仍要亲自验证、考虑缓解条件，必要时还得写概念验证。也就是说，taskflow 是放大器，不是替代者。它在「发现」这一步把人的覆盖面做大，但「这到底危不危险、能不能利用」仍然归人。对安全团队，这也是个直接的采购提示：别指望 agent 一键出权威结论，真正的竞争力在「agent 先跑一遍 + 人做终审」的分工。
辩证看：效率来自结构，而非模型多强
需要打折看的地方在于泛化。Taskflow Agent 目前围绕移动端审计成形，换到服务端、固件或业务逻辑复杂的系统，任务流要不要重写、提示词怎么迁移，仍要实测；Copilot 许可与高级模型请求的依赖，也意味着它不是一个零成本的开箱物。此外，24 个漏洞是自报口径，独立复现与厂商确认的节奏尚未完全公开。关于是否会在更多语言或平台铺开，官方暂未披露更多细节。
行业含义：agent 安全化的好用法，是「管住它干什么」
把这套方法和今年的 agent 安全走向对照看，有个共识在成形：与其追求更聪明的通用 agent，不如把「它能干哪类事、按什么步骤干、谁来收尾」设计清楚。无论是 GitHub 的 taskflow、各家的护栏，还是运行隔离，本质都是把 agent 的自主度装进可控结构里。对写安全或审计 agent 的团队，这比单纯堆模型能力更经得起生产检验。
结语
GitHub 安全实验室用定向 taskflow 让 agent 挖出 24 个安卓漏洞，证明价值不在模型多强，而在把开放式聊天换成可复现的窄任务流。它的意义是给安全审计提供一套可重复的首轮筛查，真正的裁决仍交回研究者。至于这套结构能否跨平台复用，仍要看后续实测。