wigolo 让 Agent 自主上网：真正要防的是权限放大，不是“86%评分”
让 AI Agent 自己“计划—搜索—抓取—综合”最危险的地方，不是它会不会偶尔搜错，而是网页内容一旦影响后续工具调用，错误就可能从“读错一段文字”升级成“做错一个动作”。对准备把 wigolo 接进正式工作流的人，先看权限边界，再看功能数量。
wigolo 当前 package.json 为 0.2.1，项目 README 仍标记 public beta；它提供 research 和 agent 等自动化能力，其中 agent 被官方描述为会自主执行 plan → search → fetch → extract → synthesize 的 gather loop，并带步骤日志和时间预算。
源 源
提示注入风险是真问题，但不能写成“项目完全没防”
所谓间接提示注入，人话就是：网页里混进一段看起来像给 AI 的命令，模型把网页内容误当成自己的操作指令。只要 Agent 后面还能继续调用工具，这类误判的后果就可能比普通摘要错误更大。
wigolo 自己的 SECURITY.md 把“fetched or crawled remote content could affect the host”列为特别关注的安全范围之一。这至少说明维护者承认：远程网页内容影响宿主环境，是需要专门盯住的攻击面。源
但现有一手代码也不支持“它完全没有提示注入防护”这种绝对说法。项目的 AI challenge 处理代码会把从页面读到的 instruction 明确包在 UNTRUSTED page content 标记里，并要求模型把它当数据而不是命令；代码注释直接把这称为 prompt-injection hardening。源
这里真正的未知项是：这种硬化是不是已经覆盖 research、agent、抓取结果到 LLM 合成的所有路径。本文实际检索到的是一条明确有防护的 AI challenge 路径和一份把远程内容影响宿主列为重点的安全政策，没有取到足以证明“整个自主 Agent 链路已经系统性隔离不可信内容”的一手材料。
所以，把“提示注入”定性为需要防的残余风险是成立的；把它定性成“已证实的系统性漏洞”则证据不足。
无人值守之前，先把 Agent 能做的事砍到最小
wigolo 的优势恰恰也是风险来源：同一个工具面同时具备搜索、抓取、提取、研究、Agent 循环等能力。源
如果你的 Agent 只是读取公开网页、返回证据，提示注入最坏通常停留在错误答案或多余请求。可一旦宿主还给它文件写入、代码执行、凭据访问、Webhook 或其他高权限工具，网页里的恶意文本就可能借“研究流程”放大影响。这一段是基于权限模型的风险推断，不是本文已经复现了某个 wigolo 漏洞。
实际部署时，应该把“搜索工具是否安全”改成“这一条自动化链路即使被网页诱导，最多能做什么”。读权限和写权限分开、联网抓取和本机执行分开、研究 Agent 和生产变更分开，比相信模型会自动识别恶意网页可靠得多。
单人维护不是原罪，但意味着你不能把项目当 SLA
README 公开写明，项目由“the one developer who wrote the code”维护，并依赖 sponsor、Buy Me a Coffee 等支持；项目还明确表示没有付费层。源
这不等于代码质量差。它真正改变的是故障处理预期：如果你的生产链路依赖一个 public beta、单一主要维护者的工具，就不能默认获得商业 API 那种合同化支持、备用团队和固定升级窗口。
项目 SECURITY.md 给出的公开承诺是：安全漏洞通过 GitHub 私密报告，初步响应目标是“within a few days”；public beta 期间，安全修复针对最新发布版本。源
所以，正式使用时最重要的不是猜“维护者会不会跑路”，而是自己有没有版本锁定、回归测试、降级方案和替代通道。能随时切回其他搜索服务，单人维护风险就从“单点停摆”降成“切换成本”；完全绑死，风险才会放大。
AGPL 会增加商业集成成本，但不是“禁止 SaaS”
wigolo 使用 GNU AGPL-3.0-only。源
AGPL 第 13 节要求：如果你修改了受许可程序，并让用户通过网络与这个修改版交互，就要向这些远程用户提供相应源码。源
这会让“我把 wigolo 深改后做成闭源网络服务”变得不方便，因为修改部分不能简单当成私有后端继续封闭。对 SaaS、AI IDE、Agent 平台来说，这确实会增加法务和架构评估成本。
但“AGPL 挡住 SaaS”说得太满。项目 FAQ 自己说明：在公司内部直接使用可以；义务主要落在“修改 wigolo 本身并把修改版作为网络服务运行”的情形。仅仅让自己的产品调用 wigolo，并不自动等同于必须把整个产品开源。源
商业采用要做的是明确“修改了什么、怎么部署、网络用户实际在与什么交互”，而不是看见 AGPL 三个字就直接判死刑。具体产品结构仍应由自己的法务按许可证正文判断。
0.86 不是“86%事实正确”
README 给出的示例结果里，evidence_score 包含 final: 0.86、semantic: 0.91、lexical: 0.78、engine_consensus: 3。官方对它的描述是可解释的 per-result score，用来展示相关性、词法和多引擎信号。源
这里没有一手依据把 0.86 翻译成“这条事实有 86% 概率是真的”。它是排序／证据信号分数，不是经过校准的事实正确率概率。把 0.86 当成 86% 置信概率，是使用者自己多加了一层含义。
这条区别对自动化很关键。排名分可以帮 Agent 决定先看哪条结果，却不能替代来源独立性、原文核对和交叉验证。多个搜索引擎同时命中同一条转载链，也可能得到高一致性，但“一致出现”不等于“独立证实”。
我会把 wigolo 放在哪一层
用它做本地搜索、抓取、证据缓存，可以把风险限制在“信息层”。让 research／agent 自动跑多步流程，可以，但先限定网络范围、时间预算和宿主权限。
真正不该直接做的是：把一个 public beta 的自主研究 Agent 与高权限执行工具绑在一起，再因为输出里出现 0.86 这样的数字，就默认它足够可信。
飞出国判断这类 Agent 工具时，不看“工具多不多”，先看错误能走多远。搜索错一次可以人工改；网页提示注入如果能一路传到代码执行、文件改写或外部系统写操作，才是需要优先封住的风险。