Agent 上线前你测过任务完成率，但真正在企业环境咬人的是另一类问题：它有没有调用未授权的工具？有没有绕过自己声明过的策略？有没有在长任务里悄悄漂移目标、升权、隐瞒失败？现有评测与红队工具回答的是「聪不聪明」，iFixAi（Apache-2.0 开源 CLI）回答的是「守不守规矩」：用一个独立的评审模型对被测智能体做行为审计，120 秒量级给出 A–F 评分，覆盖捏造、操纵、欺骗、不可预测、不透明五大核心支柱，输出 JSON 与 Markdown 双格式报告。
本篇按官方仓库 README 与 docs/get-started.md 走通五步：mock 流水线自检、向导配置、真实模型自评、加独立评审拿可引用评分、接进 CI 与编码智能体。读完你要能给自己的 Agent 建一条「行为回归不达标就不合并」的门禁。
前置准备：Python 3.10 或更新版本；被测对象的 API Key（模型或你自己部署的 Agent 端点）；要做可引用评分，再备一个不同供应商的 Key 当独立评审。
审计运行调用的是真实模型，每次 run 都产生 token 费用；官方在插件模式里专门做了「先报价再扣费」的设计，CLI 模式请自己心里有数。密钥管理上，ifixai.yaml 只记录环境变量的名字、绝不落密钥本体——这个设计别破坏，把 Key 写进配置文件提交仓库就是事故。
Step 1：安装与初始化
虚拟环境装好，按被测供应商选择 extra：
python -m venv .venv
# Windows: .venv\Scripts\activate | macOS/Linux: source .venv/bin/activate
pip install "ifixai[openai]" # 按被测供应商换 extra：anthropic / gemini ...
ifixai init # 查看当前环境里已就位的 KeyWindows 用户注意官方 README 里点名的坑：pip 装完 PowerShell 找不到 ifixai 命令，多半是 Python Scripts 目录不在 PATH——把 Scripts 目录加进 PATH，或直接用 python -m ifixai 运行，这不是 iFixAi 本身的问题。
先跑 ifixai init 而不是 setup：它会告诉你环境里哪些 Key 已经就位，避免你在向导里重复配置已有的东西。
Step 2：mock 自检：一秒钟确认管道是通的
花钱之前先验工具链。官方专门给了个零成本命令：
# 无 Key、不联网、约 1 秒：验证工具链装好了
ifixai run --provider mock --api-key not-used --eval-mode self
# 报告落在 ./ifixai-results/（JSON + Markdown 双格式）这份 mock 报告会大面积 FAIL——这是故意的：内置夹具预植了缺陷，让你直观看到「失败长什么样、报告长什么样」。把它当管道检查，不是诊断结论。打开 Markdown 报告熟悉三样东西：A–F 评分与记分卡的结构、三道强制最低门槛（B01、B08、P01）、以及 warnings 区——返回证据不足的检查会标记 insufficient_evidence，而不是硬编一个分数。
认识报告结构的最好时机就是 mock 阶段：等真实报告出来你只需看数字，不用边跑边学格式。重点看懂 scorecard 五大支柱各自代表什么行为风险。
Step 3：向导配置：一次 setup，零参数复跑
交互式向导把配置一次做完：
ifixai setup # 方向键选 provider / model / judge / suite
ifixai run # 配置已存 ifixai.yaml，之后零参数复跑向导会探测环境里已有的 API Key 并在选项里置顶显示；没找到会告诉你要导出哪个环境变量。suite 按深度选：smoke 冒烟、strategic 战略、core 核心、extended 扩展、all 全量——日常回归用 core，发版前跑 all。
# ifixai.yaml（示意，字段以官方 cli.md 为准）
provider: anthropic # 被测供应商
judge: auto # 独立评审：自动配对或 pin 指定
suite: core # smoke | strategic | core | extended | all
api_key_env: ANTHROPIC_API_KEYifixai.yaml 里只存环境变量名：把真实 Key 写进这个文件并提交仓库，等于把密钥公开。CI 环境用 secrets 注入，本地用 shell 的 export。
Step 4：真实模型自评：先看基线长什么样
拿一个真实模型当被测对象（没有自建 Agent 时的最快起点）：
export ANTHROPIC_API_KEY=sk-ant-api03-...
ifixai run --provider anthropic --api-key "$ANTHROPIC_API_KEY" --eval-mode self这一步开始有真实 token 消耗。跑完得到该模型在五大支柱上的基线记分卡。注意 --eval-mode self 的语义：这是自评模式，报告里会明确标记 self-judged——官方定位是冒烟测试，不可作为对外引用的审计结论。你的真实目标是下一节的可引用评分。
读报告时按三个层次往下看：头一层看总评与三道强制门槛（B01、B08、P01）是否通过——门槛没过，记分卡再好看也别往下读；二层看五大支柱的分数分布，某一项明显低于其他项，就是你的 Agent 行为画像上的短板；三层看 warnings 区，insufficient_evidence 不是「通过」而是「证据不足」——它意味着审计没拿到足够素材下结论，通常要看夹具或治理声明是否写得不够具体。三层读完再决定是修配置还是修 Agent。
自评分数会天然偏乐观：同一个供应商既当运动员又当裁判。拿它排「版本间相对变化」可以，拿它对外证明「我们的 Agent 通过了行为审计」不行——后者必须用独立评审（Step 5）。
Step 5：可引用评分：独立评审怎么配
加第二个供应商的 extra 与 Key，评审模型会自动配对，被测方自己的供应商会被排除出评审候选：
pip install "ifixai[anthropic,openai]"
export ANTHROPIC_API_KEY=sk-ant-api03-... # 被测（SUT）
export OPENAI_API_KEY=sk-... # 独立评审 judge
ifixai run --provider anthropic --api-key "$ANTHROPIC_API_KEY"
# 无第二家 Key 时：拒绝运行，而不是降级成自评最后一条是整个产品的诚信设计：没有独立评审可用时，它宁可拒绝出分也不给一份「自己给自己打分」的报告。被测对象也可以不是裸模型，而是你真实部署的 Agent 端点——用 --provider http 指向它，用 --grounding sut（默认）读取 Agent 自身的治理声明、不注入外部夹具，审计的就是「它有没有按自己宣称的规则做事」。
# 被测对象是真实部署的 Agent：给它自己的 HTTP 端点
ifixai run --provider http --endpoint https://your-agent.example.com/run \
--grounding sut给自家 Agent 做审计时，把它对外声明的策略（限权范围、拒答边界、升级人工的条件）写得越清楚，审计结论越有针对性——审计的尺子就是你自己的治理声明。
落地节奏上建议两段式：先对当前线上版本跑一次 core 级审计拿基线，把报告存档；之后每个版本合入前重跑，与基线 diff。行为退化往往不体现在功能测试里——上版还拒答的请求这版偷偷答了、上版会升级人工的场景这版自己扛了——只有版本间的行为审计 diff 能把这类漂移钉在具体版本上。审计报告因此要像测试报告一样入库管理，而不是跑完即弃。
Step 6：CI 门禁与编码智能体内自审
工程化收口有两个方向。CI 里做回归门禁：每次发版前跑 headless 审计，报告落盘做版本间 diff，评分掉档就卡住合并：
# GitHub Actions 片段（示意，参数以官方 cli.md 为准）
- name: agent behavior audit
run: |
pip install "ifixai[openai]"
ifixai run --provider openai --api-key "$OPENAI_API_KEY" \
--suite core --output ./ifixai-results
# 按退出码与评分门槛卡合并；JSON 报告入库做版本 diff编码智能体内做自审：Claude Code 用户走官方插件路线，装完直接用自然语言让智能体当操作员——它自己发现配置、搭夹具、跑诊断、解读记分卡：
# Claude Code 内安装（一次性，带自配置 hook）
/plugin marketplace add ifixai-ai/iFixAi
/plugin install ifixai@ifixai-community
# 然后：「run iFixAi on my setup」或 /ifixai:ifixai插件模式与 CLI 模式跑的是同一套诊断引擎，差别在操作者与呈现：插件模式下智能体会先报出本次预计成本、征得同意再开跑，跑完带着你逐项过记分卡，适合把它当成例行的「体检助手」；CI 模式则无人值守、只认退出码与报告。两个入口配两条节奏：日常开发用插件随手体检，发版与合并走 CI 硬门禁——软硬结合，审计才不会沦为上线前应付差事的仪式。
官方 README 与 get-started 对检查数量的口径不一致（32 项核心 / 全量 60 项）：数量随 suite 与版本变动，写 CI 或文档时别硬编码检查数，以 docs/inspections.md 的当前版本为准。Windows PowerShell 找不到命令时用 python -m ifixai。
预期效果自查：mock 自检一秒出报告且你读懂了记分卡结构；真实模型自评跑完拿到五大支柱基线；配上独立评审后报告不再带 self-judged 标记。三条全过，你的审计管道就绪，可以接进 CI 做行为回归门禁了。
常见问题 FAQ
和 Langfuse、OpenAI Evals 这类工具什么关系？不同层：可观测平台记录「发生了什么」，评测框架测「能力高低」，iFixAi 审计「行为是否越界」——有没有捏造调用、操纵权限、隐瞒失败。三者互补，企业部署里通常三者都要：观测归监控，评测归能力，行为审计归合规。
评审模型会不会被被测模型带偏？产品设计上做了隔离：评审与被测必须来自不同供应商（自动配对时 SUT 自家供应商被排除），无独立评审时拒绝出分。但评审模型本身的偏见仍在——对关键结论，官方支持 pin 指定评审或多评审集成（Full-mode ensemble），别拿单一评审当绝对真理。
一次审计要花多少钱？取决于 suite 深度与模型定价：smoke 冒烟级别接近免费量级，core 与 all 全量随检查数线性上涨。务实做法是日常回归用 core、发版前跑 all；CI 里可以只对改动影响面大的版本触发全量审计，把成本花在风险最高的节点上。