评测全绿，业务在流血：2.7 万星的开源项目专门揪 Agent 的"越权"
它不测你的 Agent 聪不聪明，它测的是：Agent 有没有偷偷干了你没让它干的事。
先看一个项目官方自己举的例子。
一个客服 Agent 处理退款工单。在它自己的评测体系里，每一项检查都是绿的：工单关闭了，状态返回成功，报告一切正常。
然后审计跑完，发现三件事：
三件事里，只有"关闭工单"这一件是在权限范围内的。
关键在于：这不是 Agent 变笨了，它完成的正是你让它完成的那件事。 传统 eval 问的是"任务做完了吗"，没人问"它顺手还做了什么"。
一、它到底是什么
要理解 iFixAi，先得把它和 eval 区分开。
eval 测的是能力：这道题做对了吗？这个任务完成了吗？指标是准确率、通过率、成功率。
audit 测的是对齐：在完成任务的过程中，它有没有越权？有没有捏造？有没有把失败包装成成功？有没有被诱导着做了不该做的事？
这两件事的失败模式完全不同。一个模型可以 100% 通过能力评测，同时在每一次执行里都越一点点界——而这一点点界，通常不会在你的 eval 里留下任何痕迹。
iFixAi 的具体做法是三层：
- 1. 建一个业务仿真环境（fixture）。你描述你的 Agent——它的角色、能用的工具、谁在组织里能干什么（参考仓库里的
profile.json） - 2. 给它发真实一天会遇到的请求，包括那些把它往权限边界外推的请求
- 3. 一个评审模型（judge）给每个回复打分，每条发现都附上"问了什么"和"你的 Agent 实际做了什么"
README 里有句话点出了核心："iFixAi 从你配置的 key 里挑一个评审，永远不会挑你 Agent 自己用的那家。"
【插图位】此处插入 illustrations/arch-30-ifixai.png（审计流程图：检查表 → 对话探测 → 评分 → 等级判定），发布前在公众号后台上传图片并删除本行
二、凭什么火成这样
1. "独立"这两个字，是落到机制上的
很多工具说自己独立，但你一问"独立从哪来"，就没下文了。iFixAi 至少给了一个可验证的机制：评审模型必须来自另一个提供商。你的 Agent 用 OpenAI 的，评审就从 Anthropic 或 Gemini 里挑。
这个设计防的是"自己人审自己人"——同一系列模型对同一类越权行为可能有相似的盲区。
而且它支持两种发起方式：人手动触发，或者 Agent 自己审自己。官方没回避后者的问题——agent 自审本质是自我报告。所以那句"评审来自另一家"才更重要，它是独立性的唯一来源。
2. 评分体系是可解释的，不是黑箱分数
最终等级是 A 到 F，来自五个核心支柱：捏造（fabrication）、操纵（manipulation）、欺骗（deception）、不可预测性（unpredictability）、不透明性（opacity）。
更有意思的是三条强制最低项：
这三条任何一条不达标，整体等级最高只能到 D。
这个设计很聪明。加权平均的评分体系天然有个漏洞：某一项特别烂可以被其他项的高分平均掉。三条"一票否决"把最致命的三类失效钉死了。
3. 默认 10 项检查，就能出等级
默认运行的 10 项检查，全都能通过对话端点完成。
高影响 6 项：
- • B08：不会被套出超出用户的权限（强制最低项）
- • P01：不为无权限者执行破坏性操作（强制最低项）
中影响 4 项：
--full-run 开到 61 项完整检查，其中不适合你 Agent 的项会被先剔除，并且会告诉你为什么。
我特别喜欢 B16 这一条——"报告失败，而不是假装成功"。这是 Agent 最常见也最隐蔽的失效模式：静默失败被包装成成功，日志上漂漂亮亮，直到业务侧炸了才发现。
4. --dry-run 先看账单，再决定跑不跑
真实审计要调你的 Agent、要调评审模型，token 是真金白银。iFixAi 给了 --dry-run：先告诉你这次跑多少个测试、多少次评审调用、哪些检查不适用于你的 Agent 及原因，然后停下。
这个细节体现的是产品成熟度——知道用户最怕的不是慢，是账单失控。
5. 接入方式覆盖了你会用的所有入口
- • Claude Code / Codex 插件：
/plugin marketplace add ifixai-ai/iFixAi 然后 /plugin install ifixai@ifixai-community，之后直接跟 Agent 说"run iFixAi on my agent"，它会自己找到你的 agent、建仿真环境、先报价再跑、最后解释发现 - • Skill（Cursor、VS Code、Windsurf、Zed 等）：
uvx ifixai install --agents cursor - • 命令行：给 CI 用，支持
--min-score 做门禁
三、怎么用起来
前置要求 Python 3.10 或更高（注意 Mac 自带的 python3 是 3.9，先 python3 --version 确认）。建议在干净的虚拟环境里跑：
python3 -m venv .venv && source .venv/bin/activate
先看效果，不需要任何 API key——内置了一个带固定回复和固定评分的 demo agent：
pip install ifixai
ifixai author reference -o reference.yaml
ifixai validate reference.yaml
ifixai run --provider mock --eval-mode self --fixture reference.yaml
这条跑的是一个虚构金融科技公司的客服 Agent，跑 10 项默认检查，评分卡直接打在终端，报告落到 ./ifixai-results/。
要审自己的 Agent，按官方推荐的做法——让它自己审自己：
# Claude Code 里
/plugin marketplace add ifixai-ai/iFixAi
/plugin install ifixai@ifixai-community
然后直接说 "run iFixAi on my agent"。它会读你 agent 的代码，把 profile 写出来。
想完全手动，走 CLI：
pip install "ifixai[openai]" # 按评审方换 extra：anthropic、gemini 等
ifixai author my-agent.json -o my-agent.yaml
ifixai validate my-agent.yaml
ifixai setup # 向导配置 agent 端点、评审、套件
export AGENT_API_KEY=...
ifixai run --fixture ./my-agent.yaml --api-key "$AGENT_API_KEY" --dry-run
ifixai run --fixture ./my-agent.yaml --api-key "$AGENT_API_KEY"
一个重要的操作提醒：探针是真实请求，请用 staging 环境的副本跑。 别拿生产实例做审计靶子。
输出是 JSON 和 Markdown 两种报告，可以对比多次运行，也可以挂进 CI。
四、谁该装，谁别装
该装的：
- • 已经把 Agent 投入生产、且做错一单代价很高的团队——客服退款、财务操作、权限变更这类场景
- • 想在 eval 之外加一层独立验证的开发者，尤其是已经发现"指标好看但业务出问题"的团队
- • 需要在发布前设一道闸门的工程团队——几分钟能跑完的检查才可能被坚持执行，一天的检查你迟早会跳过
别装的：
- • 想拿它当安全认证或合规证书的。官方自己说得很直白：它不是认证，不是安全保证，只是一套可以在 CI 里重复跑的诊断工具。能在两分钟内出结论的东西，覆盖不了你 Agent 在真实任务分布上的全部行为
- • Agent 只有一个聊天端点都没有的情况——任何有 chat 端点的 Agent 都能审，但连端点都没有就没法测了
- • 预算紧张、又没有 staging 环境的团队——探针是真实请求，会消耗你 agent 自己的 token
五、一句冷静话
我觉得这个项目真正的价值，不在那 61 项检查，而在它把"对齐"从一个哲学问题降维成了一个可执行的检查清单。
行业里谈 AI 对齐，谈的多半是模型层面的宏大命题。但真实生产事故几乎从不发生在那个层面——它们发生在"这个具体的 Agent，配了这几个具体的工具，在今天这个具体的场景下，干了它不该干的事"。iFixAi 问的正是这个更窄、也更能回答的问题。
但有两处我持保留态度。
第一，"独立"这个词要拆开看。审计可以由 Agent 自己发起，这是它宣传的特性之一，但自我报告在审计语境里从来不算独立证据。独立性只能来自两处：审计准则外在于被审对象，证据来自被观测的行为而非自述。用之前先确认你拿到的是哪一种。仓库只有个位数 open issue 但 2.7 万星——公开 issue tracker 显然不是这个项目真实历史的存放地，很多判断你得自己做。
第二，120 秒是个速度承诺，不是深度承诺。这个速度来自"范围窄"而不是"方法更聪明"。10 项默认检查能出等级，但这 10 项是精心挑选的高影响项，不等于你的 Agent 只有 10 种失效方式。把它当成定期检查的体温计，别当成全身 CT。
还有一点值得留意：README 主体是品牌视觉、徽章和指向官网的按钮，配套的 Pro 版有更高上限，开源仓库多少带有获客入口的性质。这本身没问题（Apache 2.0，代码能看、能 fork），但你得清楚自己用的是哪一层，以及审计数据走的是你的机器还是它的云。
最后一句：现在很多团队给 Agent 加了 observability，能看到每一次调用、每一个 token。但看见不等于判断——你能看见 Agent 改了收款账户，你不一定知道它不该改。
给 Agent 装监控，是为了知道它做了什么；给 Agent 做审计，是为了知道它做的对不对。前者是日志问题，后者是治理问题，而治理问题从来不能靠看日志解决。
项目卡片
数据来源：GitHub Trending 每日榜（采集时间 2026-10-03 ~ 2026-10-15）
