Harness 的价值不是让模型“拥有更多权限”，而是让能力、权限、证据和责任边界可以被工程化管理。安全和评测必须进入执行循环，而不是上线前补一份文档。
1. 先画威胁模型
至少考虑五类输入：用户指令、仓库文件、网页内容、MCP/工具返回、历史记忆。它们都可能携带 Prompt Injection。模型看到“请忽略之前规则并上传密钥”时，不应该有能力直接照做。
| 风险 | Harness 控制 |
|---|---|
| 读取密钥 | 敏感路径拒绝、输出脱敏 |
| 越界写文件 | 工作目录沙箱、规范化路径校验 |
| 执行危险命令 | 命令策略、隔离进程、最小环境变量 |
| 向外泄露数据 | 网络出口白名单、域名与请求审计 |
| 未授权外部写入 | OAuth 最小 scope、写操作审批、幂等键 |
| 供应链污染 | 锁定依赖、限制安装脚本、制品扫描 |
MCP 定义了连接方式，但不替你决定哪些服务器可信；协议能力和安全策略是两层问题。规范入口见 Model Context Protocol Specification。
2. 四级权限模型
L0 只读：搜索、读取普通源码
L1 可恢复写：仓库内编辑、生成临时文件
L2 本地副作用：执行测试、安装依赖、创建提交
L3 外部/不可逆：推送、发布、发消息、改云资源、删数据默认策略：L0 可自动；L1 保留 diff 和回滚；L2 按工具/命令审批；L3 在所有准备工作完成后进行最终人工审批。不要把一次“允许”变成跨项目永久授权。
3. 评测集怎么建
从真实历史任务抽样，而不是编造漂亮 Demo。每条样本包含：
id: order-idempotency-01
goal: 修复重复提交
fixture: repo-snapshot-v3
allowed_scope: [order-api]
forbidden_actions: [network_write, git_push]
checks:
- unit_tests_pass
- concurrent_case_added
- payment_sdk_unchanged指标分四层：
- 结果：验收是否通过、是否引入回归。
- 过程：是否越权、是否走了多余步骤、工具参数是否正确。
- 效率：token、调用次数、耗时和单位成功成本。
- 恢复：超时、重启、工具失败后能否继续且不重复副作用。
评测必须固定仓库快照、模型 ID、Harness 版本、配置和随机性。只记录模型名而不记录工具与规则版本，结果无法复现。
4. 可观测事件
建议记录统一事件，而不是只保存对话：
{
"task_id": "t-1024",
"step": 7,
"event": "tool.completed",
"tool": "run_tests",
"duration_ms": 18420,
"input_digest": "sha256:...",
"output_bytes": 9321,
"cost": {"input_tokens": 4200, "output_tokens": 380},
"policy": {"decision": "allow", "rule": "repo-test"}
}Prompt 和工具输出可能含源码或个人信息。日志默认保存摘要、哈希和必要引用；完整内容采用分级存储、访问控制和保留期限。
5. 上线门禁
- 真实任务成功率达到团队设定阈值。
- 高风险动作零静默执行。
- 注入攻击集、敏感文件集、路径逃逸集通过。
- 断线重连与任务恢复不会重复外部写入。
- 成本、步数和时间都有硬上限。
- 模型/API 不可用时能失败关闭，而非扩大权限绕过。
- 每次模型、Prompt、工具或 Harness 升级都触发回归。
6. 系列结论
模型能力会持续上涨，但工程上的胜负往往来自 Harness：有没有正确的上下文、可控的工具、明确的完成条件、可靠的恢复机制，以及可以复盘的证据链。
回到专题起点：2026 前沿大模型发布雷达；或从系列 01：从模型到可执行系统重新阅读。