Coding Agent 沙箱

• 字符串匹配的绕过方式（引号、别名、变量）
• Shell 组合（|、&&、;） 与解释器（python/shim）逃逸
• 子进程与二级执行的控制

字符串匹配可被轻易绕过：rm -rf / 可写成 r""m -rf /、rm -$arg、\rm、base64 解码后执行、python -c "os.system(...)"、sh -c 组合等。因此不能只匹配命令字符串，而应解析到真正的执行对象：用 Shell 解析器（如 bash -c 的 AST）提取实际命令与参数，然后在子进程边界上做控制。对解释器命令（python、node、perl）要限制其启动参数或放到受限环境，对子进程要递归跟踪（agent 起的进程再起的进程），用 seccomp/Landlock 等系统级过滤而非命令文本匹配。

allow/deny list 是"最后一道文本层"，真正的安全边界必须在系统调用/进程层。字符串匹配只是惯例，真正的控制要解析命令结构、限制解释器、递归管理子进程，并与系统级沙箱结合。

• 路径沙箱限制可访问的文件范围
• Worktree 限定写入范围
• 容器与网络出口策略隔离

路径沙箱把 Agent 可读写的路径限制在 Worktree 内，拒绝访问 .ssh、.env、~/.aws、系统密钥等敏感路径；Worktree 作为唯一可写范围，任何出界写入被拒绝。容器提供文件系统与进程隔离，Agent 在容器内运行，宿主机密钥通过只读挂载或环境变量白名单注入。网络出口策略用白名单 DNS/端口，只允许访问必要的外部服务（如拉取白名单依赖），禁止向任意地址外传数据。四者配合：路径沙箱限文件、Worktree 限写、容器限进程、网络策略限外联。

读取密钥与修改仓库外文件是两类越权。路径沙箱+Worktree 拦截文件读写，容器+网络出口拦截进程与外联，形成纵深防御，单靠任何一层都被绕过。

• 二次确认绑定确切命令与参数
• 防重放（一次性、时间戳、幂等）
• 审批与执行的一致性校验

二次确认不能只问"确认删除吗"，而要展示确切命令与参数（如 rm -rf /deploy/old-app、git push origin main、发布到哪个环境），并用哈希绑定命令 + 参数 + 环境 + 时间戳。确认后执行时校验该哈希仍匹配，防止 Agent 在确认后篡改参数。防重放：审批用一次性 token（仅一次有效）、带短有效期与随机数，相同操作重复确认不生效；用幂等键保证同一次操作只执行一次。审批记录参数哈希与批准人，供审计。

危险操作的风险在于"确认了 A 却执行了 B"或"重放确认"。绑定确切参数哈希 + 一次性有效 token + 幂等，保证批准的就是执行的确切内容，且不可被重复滥用。

• 依赖来源与供应链校验
• 测试脚本的静默执行风险
• 仓库内提示注入的检测

依赖层面：只从可信源拉取，校验 checksum/签名，用锁文件（lockfile）固定版本，运行依赖扫描（已知漏洞、可疑 install 脚本），默认拒绝未知来源或 require 授权。测试脚本层面：不要把仓库内未审查的脚本当作可信指令执行，检测脚本中的危险模式（网络外联、读取密钥、写敏感路径），在沙箱中隔离执行。提示注入：把仓库内 README、Issue、测试脚本中的内容视为"不可信数据"，不作为指令执行，通过在提示中明确区分"系统指令"与"外部内容"，并对可疑注入模式（如"忽略以上指令"）做检测。

恶意包与提示注入都利用了"Agent 信任外部内容"。供应链校验+锁文件+扫描防恶意包，把外部内容降级为数据+检测注入模式，防提示注入，共同降低 Agent 被诱导执行危险操作的风险。

• 长期 Token 的风险
• SSO 与短期凭证（STS、临时密钥）
• 最小权限与按需授权

长期 Token 泄露即长期有效，风险大。替代方案：用企业 SSO（OIDC/SAML）做身份认证，Agent 通过 OIDC 换取短期凭证（如 AWS STS 临时密钥、GitHub App 的短期 token），凭证有效期短（如 5-60 分钟），过期自动失效，降低泄露危害。权限上按最小权限原则：Agent 只能访问任务所需的最小资源，权限按角色/仓库/环境动态授予，任务结束即回收。用 OIDC 凭据链（Workload Identity）让 Agent 无需落盘长期密钥。

长期 Token 是集中式风险点。SSO 管身份、短期凭证管时效、最小权限管范围，三者结合让 Agent 凭证"短命、最小、可追溯"，即使泄露影响也有限。

• 审计日志的完整性与结构化
• diff/命令/审批的记录
• 密钥与客户数据脱敏

日志结构化记录每个关键事件：工具调用（工具名、参数、结果摘要）、命令（处理后的命令哈希）、diff（改动的文件与摘要）、审批（批准人、时间、参数哈希）、结果（成功/失败、输出）。脱敏上：密钥、token、密码、客户数据在写入前用检测规则（正则、secret 扫描、字段白名单）替换为脱敏标记或哈希，日志中只保留必要信息。脱敏在采集端完成，避免明文进入日志系统；diff 中删除密钥地址与客户 PII，只保留结构摘要。同时控制日志访问权限与保留期。

审计日志既要"全"又要"安全"。结构化记录各环节且脱敏，既满足可追溯与合规，又防止日志本身成为密钥与客户数据的泄密渠道。

• 仓库内容注入的入口与特征
• 静态检测与动态验证
• 内容与指令的隔离

检测分静态与动态：静态检测扫描仓库文本中的注入模式（"忽略以上指令"、"以系统身份执行"、隐藏指令、高熵指令文本、可疑的 base64/编码载荷），用正则与分类模型识别；动态验证在 Agent 读取内容时，把外部内容标记为"数据"而非"指令"，用提示边界隔离（如 <data> 包裹 + 明确"外部内容不可执行命令"），并记录 Agent 是否据此执行了异常操作。对高风险内容（如新引入的 README、第三方 issue）提高检测阈值，必要时人工审查。检测到后阻断并告警。

提示注入利用 Agent 无法区分"数据"与"指令"。静态特征检测 + 读取时提示隔离 + 动态行为监控，形成双层防护，既识别已知模式也约束未知诱导。

• 事件响应流程（撤销→隔离→取证→回滚）
• 凭证撤销与访问终止
• 证据保全与变更回滚

事件响应按序执行：①撤销凭证——立即吊销 Agent 的短期凭证、Token、SSO 会话，删除其挂载的密钥；②隔离工作区——把 Agent 的容器/Worktree 与网络断连，冻结其进程，防止继续扩散；③保全证据——保留审计日志、工具轨迹、命令、diff、内存快照，用只读镜像归档，保证证据可被取证；④回滚变更——基于基线或已知好 Checkpoint 回滚被修改的文件，重新验证受影响服务。全程记录时间线，供复盘与合规。

安全事件需"先止血、再取证、后修复"。撤销凭证保证权限终止，隔离防止扩散，保全证据支撑调查，回滚恢复服务，四步不可颠倒，避免在取证前就破坏现场。

• Agent 与 CI/CD 的职责边界
• Agent 测试通过≠可合并
• 合入门禁为不可绕过的安全底线

职责划分：Agent 负责"产生与验证代码"（写实现、跑本地测试、自检），CI/CD 负责"权威的集成、构建、测试、部署门禁"。Agent 的测试通过是其"自证"，而 CI/CD 在独立环境、用权威配置重新构建并跑全量测试与安全扫描，是"他证"。因此 Agent 即使本地测试通过，也不应绕过 CI 门禁，因为 Agent 可能只跑了部分测试、环境不同、或测试被污染；只有 CI 门禁独立通过才可合并。合入门禁是治理底线，需人工/门禁系统最终把关，Agent 无权限关闭或跳过。

Agent 自证容易被其自身环境或选择性测试影响，是不可信的唯一依据。CI/CD 提供独立、权威、可审计的验证，作为不可绕过的门禁，防止 Agent 将未充分验证的代码合入主干。

• 静态模式匹配（危险命令特征）
• 动态/语义检查（解析后的实际行为）
• 检测到后的处理

静态检查扫描命令中的危险模式：rm -rf、递归删除、chmod 777、curl|bash、sh -c、sudo、dd、:(){:|:&};: 等，用规则库+正则匹配。但静态会漏掉变形（变量、编码、拼接），故需动态/语义检查：解析命令 AST，跟踪变量展开与管道，判断实际是否形成危险行为（如把 curl 输出直接交给 shell、对根目录递归删除、修改关键权限）。检测到后：默认阻止执行，交给二次确认或人工审批，并记录告警。结合 allowlist 与系统沙箱，在高风险模式下强制人工介入。

危险命令变形极多，静态规则只能覆盖已知模式。静态+动态语义检查结合，能识别"表面安全但实际危险"的变形，配合二次确认与沙箱，形成对危险操作的完整拦截。

• 审计日志的完整性、不可篡改
• 证据留存与权限控制
• 合规映射（SOX/ISO27001/SOC2）

满足合规的审计轨迹需：①完整性——记录 Agent 的每次工具调用、命令（含哈希）、diff、审批、结果、时间戳，形成不可篡改的日志（追加写、哈希链、WORM 存储）；②不可否认——绑定操作者身份（用户、Agent、审批人）与时间，有签名/哈希锚定；③证据留存——关键位置（改动、审批、环境变更）保留 diff 与快照，保留期符合合规要求；④权限控制——审计日志访问受限，修改需特权。映射到标准：SOX 要求财务相关变更的完整轨迹与复核，ISO 27001/SOC 2 要求日志、监控、访问控制、事件响应均可被审计。定期导出审计日志供外部审计。

合规审计的核心是"可验证、不可篡改、可留存"。不可篡改日志 + 身份绑定 + 证据留存 + 权限控制，满足 SOX/ISO27001/SOC2 对变更可追溯与审计的要求。

• 网络出口限制到隔离环境
• 文件与命令的范围控制
• 生产资源访问的阻断

网络层：限定 Agent 的网络出口只到 Dev/Staging 的域名与端口，禁止访问生产环境、公网外传或不必要网络；生产凭据不注入该环境。文件层：Agent 只读/写隔离环境内的资源，生产数据通过受限快照或白名单引用，不直接暴露生产后端。命令层：用 allowlist 限制命令范围，生产部署、生产数据操作、生产账号变更命令默认禁止或强审批。隔离环境与生产环境用网络分段、账号隔离、密钥隔离彻底分离，确保 Agent 无法跨环境触碰生产。

隔离执行的核心是"环境边界不可穿越"。网络、文件、命令三层限制 + 生产环境彻底分段，让 Agent 在 Dev/Staging 的权限与数据绝不触及生产，即使被完全控制也只影响隔离环境。

• 工具能力的裁剪与白名单
• 高危操作（下载、提交、支付、外传）的拦截
• 操作审计

裁剪能力：只暴露任务所需的最小工具集（如只用 navigate/click/fill/screenshot），移除或禁用高风险工具（文件下载、表单提交到外部、执行脚本、访问敏感域）。对浏览器访问做 URL 白名单，限制可访问域。高危操作（提交表单支付、下载文件、上传数据、跨站外传）在 Server 层拦截并转人工审批。审计：记录每次 browser 操作（URL、动作、产物），在 Host 层与 Server 层双重记录，便于追溯。用能力声明与最小权限结合，避免 Agent 在浏览器中执行危险操作。

Playwright 能力强但危险面大。工具裁剪 + URL 白名单 + 高危操作拦截审批 + 双重审计，把浏览器能力限制在完成任务所需的范围内，防止 Agent 在浏览器中做越权操作。

• Filesystem MCP 的路径沙箱
• host-side 二次校验的必要性
• 与 Worktree 隔离的协同

Filesystem MCP 的路径沙箱本身可能可被绕过（路径穿越、符号链接、相对路径、容错），且沙箱配置在 Server 侧，Agent 或 Server 一旦被攻破，读/写可能越界。因此必须再加一层 host-side 校验：Host 在调用前对解析后的真实路径（realpath，消除 symlink 与 ..）做白名单校验，确认落在 Worktree 内才放行，从而与 Worktree 隔离策略协同。即使 MCP Server 沙箱被绕过，Host 层仍拦截。写操作尤其要校验真实路径落在可写范围。

单层路径沙箱不可信，绕过向量多。host-side 用 realpath 归一化后再校验，形成第二道防线，与 Worktree 隔离协同，确保无论 Server 层如何，最终读写都受限在 Worktree。

• OAuth scope 的最小化
• read/write 分离
• 按需授权与审计

按任务所需收敛 scope：只做 issue 查询的 Agent 只授予 read:issues，不授予 write 权限；需要创建 release 的才额外授予 write:releases，且单独授权。用最小 scope 原则拆分权限，避免"查询一次就拿到全部写权限"。同时把 scope 与项目/组织绑定，按 Agent 任务范围限制。对 write 操作记录审计并设二次确认。scope 变更需重新授权，长期闲置的 scope 定期回收。

Sentry 的写权限（release 创建）影响面大，若与查询权限捆绑则扩大风险。按 read/write 拆分最小 scope，按需授予、按需回收，让 Agent 只拥有完成任务所需的最小权限。

• 多 Server 注入放大的机制
• 跨 Server 可信度隔离
• Host 端信任标记与审计

多 Server 共存时，模型看到的是所有 Server 内容的混合上下文，一个恶意 Server 返回的内容（工具 description、资源文本）可携带注入指令，模型可能被诱导在另一个可信 Server 上执行危险操作，从而放大风险。Host 端应做跨 Server 信任隔离：为每个 Server 维护信任等级（官方/社区/沙箱），把不同 Server 的内容标记为不同可信度，注入时用边界隔离（如 data from UntrustedServer），并限制"一个 Server 的内容能否触发另一个 Server 的工具"。对高风险 Server 的输出，模型不得据此在可信 Server 上执行写操作。审计跨 Server 调用链。

注入风险因"内容与执行工具的分离"而放大。Host 端按 Server 划分信任域、隔离内容与指令触发、限制跨 Server 调用，切断"恶意注入→可信执行"的链路。

• needsApproval 流与沙箱层的分工
• 按影响分级审批
• 双向联动（沙箱阻断→审批，审批→沙箱放行）

分工：沙箱层（seccomp/Landlock）负责"低风险自动放行、高风险静默阻断"，AI SDK 的 needsApproval 负责"高影响操作触发人工审批"。不应让每个命令都走审批，而应让沙箱层先用 syscall filter 判断命令的实际影响（如写系统目录、网络外联、改权限），低风险直接执行；只有当命中高影响规则时才把该命令标记为 needsApproval 抛给客户端审批。审批通过后沙箱层对该命令放行并记录，形成"沙箱裁决 + 审批放行 + 审计"的联动。审批粒度绑定到具体命令与参数，而非笼统放行。

每次命令都审批会拖垮效率，全部自动会漏高影响。沙箱层做静态/动态影响分级，把高影响命令才送入审批流程，实现"低风险自动、高风险人审"，两者联动而非重复。

• 信任分级标准
• 各等级对应的权限与审计
• 高风险 Server 的治理

把 MCP Server 按来源分级：官方（厂商维护、有供应链背书）、社区（第三方维护、经审查）、个人（自建/未经验证）。对应不同权限：官方 Server 可授予较完整权限并默认可信；社区 Server 需审查后授予受限权限、加强审计、隔离运行；个人/不可信 Server 放入沙箱、只读或最小权限、禁止访问敏感资源，必要时仅在隔离环境使用。分级要动态更新（Server 更新、漏洞通报会降级），并记录在审计中。高风险 Server 默认不授予写权限。

信任分级把"来源可信度"映射到"权限大小"，是治理多来源 MCP Server 的基础。分级+对应权限+审计，避免不可信 Server 获得与官方同等的危险权限。

• 外观特征不能作为 AI 生成的证据
• 审查应聚焦正确性、安全、边界与意图
• 防止误判

这些特征（过度注释、模板化、风格不符）不能作为 AI 生成的可靠证据，因为人类也可能写类似代码，且风格问题可被格式化工具消除。审查重点应放在代码的实质质量：正确性（逻辑、边界条件、并发）、安全性（注入、敏感数据、权限）、性能、可维护性、与需求的一致性、依赖与 license 合理性。AI 生成的代码尤其在边界条件、错误处理、安全上容易有缺陷，应重点核查。审查是对"代码质量"负责，而非"是否 AI 生成"。

用外观特征判断 AI 生成既不可靠也偏离审查目的。审查应聚焦代码是否会出问题、是否满足需求，把"AI 痕迹"作为次要线索而非判定依据，避免误判与漏审。

• 模糊需求的澄清方法
• 关键可验证问题维度
• 用问题驱动实现而非猜测

需求模糊时 Agent 应先提出可验证的问题而非直接编码，关键维度包括：①边界条件——输入为空、极端值、超长、并发、重复调用；②性能指标——吞吐、延迟、规模、缓存策略；③错误处理——失败语义、重试、降级、幂等；④数据与权限——数据来源、敏感字段、权限模型；⑤兼容性——版本、平台、第三方接口。每个问题应给出"可验证的验收标准"（如"QPS 达到 1000 且 P99<200ms"）。Agent 与用户确认后再实现，避免基于猜测做出错误假设。

模糊需求下直接编码是返工之源。通过提出边界、性能、错误处理等可验证问题，把隐式假设显式化，用确认后的验收标准驱动实现，提高一次通过率。

• 小 diff 降低重构风险
• 基准测试验证性能不退化
• 故障注入与安全扫描验证正确性与安全

重构证明无退化需多手段：①小 diff——重构拆成可独立验证的小步骤，每步有对应测试，便于定位退化；②测试 + 基准测试——跑全量测试验证行为等价，用基准测试对比重构前后延迟/吞吐/内存，确认性能不退化；③故障注入——模拟异常（超时、丢失、并发、错误输入）验证重构后错误处理与恢复行为不变；④安全扫描——对重构后的代码跑依赖与静态安全扫描，确认未引入漏洞或危险依赖。四者结合，配合 diff 对比，才能证明重构"只改结构不改行为"。

重构的风险是"行为悄悄改变"。小 diff 加测试证明等价，基准测试证性能，故障注入证鲁棒性，安全扫描证安全，形成对"无退化"的完整验证。

• 原型与生产的目标差异
• 生产级要素清单
• 补课流程与验收

原型为验证可行，生产为可靠可用，转生产需系统性补课：①架构决策——记录并发、扩展、依赖、容错等关键决策及其理由（ADR）；②类型定义——补齐/收紧类型与数据模型，消除 any；③单元测试——为关键路径补测试，覆盖边界与错误处理；④观测——接入日志、指标、trace、告警，明确关键指标；⑤安全扫描——依赖扫描、静态安全分析、密钥扫描、权限审查；⑥回滚方案——定义版本化、迁移、回滚与灰度发布流程。每项有验收标准，转生产前通过门禁。

原型省略的是"可靠性要素"。转生产补齐架构、类型、测试、观测、安全、回滚六类，把"能跑"升级为"可靠、可观测、可回滚、可安全上线"，避免带着原型缺陷直接生产。

• Vibe Coding 的适用边界
• 生产变更的明确规格要求
• 从探索到生产的切换点

Vibe Coding（自然语言驱动快速生成）适合低风险、不持久、无关紧要的探索原型：验证想法、做 UI 草稿、写一次性脚本、探索一个不确定的库/API 用法。而对生产变更——涉及核心逻辑、数据/资金、安全、并发、长期维护、对外契约的代码，必须切换到明确规格与验收：先写需求/接口/验收标准，再实现，配测试与门禁。切换点判断：当原型要进入主干、被他人依赖、处理真实数据或上生产时，就从 Vibe Coding 转为规格驱动。

Vibe Coding 快但不可控，适合探索"可行性与形态"，不适合生产"可靠与合规"。按风险与影响面划分，明确"何时停止自由生成、转为规格+验收"，是安全使用 Vibe Coding 的关键。

• API 幻觉的验证
• 安全与性能检测
• 依赖声明与锁文件

防止 Vibe Coding 引入问题需多层验证：①API 幻觉——对生成的 API 调用做验证（编译/运行/查文档），不盲目信任 Agent 记忆的 API 签名；②安全漏洞——跑安全扫描（静态分析、依赖漏洞扫描、密钥扫描），对高风险代码（输入处理、权限、命令执行）重点审查；③性能退化——用基准测试/负载测试对比生成前后，检测明显退化；④隐藏依赖——用锁文件（package-lock/yarn.lock/pnpm-lock）固定依赖，检查 package.json 中声明的依赖与代码实际用到的一致，防止 Agent 用了未声明的包。用 CI 门禁强制这些检查。

Vibe Coding 快速生成却可能引入幻觉、漏洞、性能问题和未声明依赖。验证（编译+扫描+基准）+ 锁文件与依赖一致性检查 + CI 门禁，把风险在合并前拦截。

• 结果导向的度量
• 避免过程指标（提示次数、代码量）
• 业务/质量指标

评价应聚焦业务价值与结果质量，而非过程投入：用"是否达成业务目标"（功能上线、用户率、性能达标、成本降低、缺陷率下降）衡量，用交付的可用功能、质量与可维护性评价。提示次数、生成代码量是过程指标，代码多不等于价值高，甚至可能有反效果（冗余代码）。应看：需求满足度、上线后的实际效果、缺陷与返工、可维护性。用覆盖业务结果的指标（留存、转化、性能、故障率）作为最终评价，剥离"AI 用了多少"的噪音。

过程指标（提示次数、代码量）易被 AI 放大且与价值无关。评价应回到业务结果与质量，用"解决了什么问题、效果如何"而非"生成了多少"来度量，避免团队为刷指标而无效生成。

• 文件系统快照/检查点机制
• 工作区镜像与中断恢复
• 变更回滚

沙箱用文件系统快照（如 copy-on-write 镜像、LVM 快照、层叠文件系统）在工作区初始化时打基线快照，Agent 的修改发生在快照上层。任务中断时，从最近检查点恢复环境与状态，避免重复初始化。需要回滚时丢弃快照以上的层，恢复到基线或某检查点，快速还原工作区。长任务周期性地打检查点（含文件状态+任务状态），中断后从检查点续跑。快照还用于取证与审计。用增量快照控制存储成本。

长任务容错的核心是"可回到任意已知好状态"。快照作为基线，检查点作为进度，中断恢复与回滚都基于快照分层实现，高效且可审计。

• 探索与生产的边界
• 防止复制粘贴绕过门禁
• 门禁的不可绕过性

允许探索：在隔离的原型环境/分支中做 Vibe Coding，明确原型不进入生产路径。防止复制粘贴绕过门禁：生产门禁（CI、测试、安全扫描、代码审查、依赖锁定）绑定到"合入生产分支"这一动作，无论代码来自 Agent 还是复制粘贴，只要进入主干就必须经过门禁。用"来源不改变门禁"的原则，让所有代码统一走构建+测试+扫描+审查；对明显复制粘贴的代码，通过扫描（重复代码检测、依赖未声明）识别并强制审查。原型通过"正式迁移流程"而非复制进入生产。

直接禁 Vibe Coding 会扼杀探索，但复制粘贴能绕过门禁。关键是让门禁绑定到"进入生产"而非"来源"，无论代码怎么来都需过门禁，从而既保留探索又不留后门。

• 过度依赖的风险
• 能力保持与学习机制
• 平衡使用与核心能力建设

缓解方法：①把 AI 定位为"加速器"而非"替代品"，强制成员理解 AI 生成的代码（Review、解释、重构），而非盲贴；②保留核心能力训练——新人先学基础编码、算法、调试，再上 AI 工具；③在 Review 中要求成员能解释为什么这样做，防止"只会让 AI 写、看不懂"；④对关键代码（架构、安全、复杂度高）要求人工独立设计，AI 只做辅助；⑤轮岗与代码评审制度保证成员持续接触底层实现。目标是让 AI 提升效率而不削弱理解与判断力。

过度依赖会削弱基础能力，造成"AI 出错时无人能修"。通过强制理解、保留核心训练、关键代码人工主导、评审制度，在提升效率的同时维持团队能力与判断力。

• 生成痕迹的常见特征
• 痕迹识别方法
• 识别目的（审查辅助而非判定）

生成痕迹可观察的常见特征：①注释风格——逐行解释显而易见的代码、模板化注释、用词机械；②变量命名——过度描述性/不自然命名、不一致命名、无意义中间变量；③错误处理——模式化 try{...}catch{...}、笼统兜底、忽略边界。识别可通过人工 Review 的敏感度训练 + 工具辅助（重复模式检测、风格统计）。但要注意：痕迹只是"审查线索"，应引导审查重点（正确性、安全、边界），而非据此判定或拒绝；对高痕迹代码加强测试与边界核查。

生成痕迹是弱信号，可能误判。识别它用于"提高该代码的审查强度"，而不是作为"AI 生成就拒绝"的根据，把线索转化为针对性的质量核查。

• 原型到生产的演进路径
• 重构成本评估
• 部分重写 vs 修补的决策

演进路径：先评估原型的质量与可复用度，判断是"修补"还是"重写"。轻度原型（结构清晰、可测）可增量重构：补测试→逐步替换脆弱的原型代码→补类型与边界→接生产要素。重度原型（乱、不可测、副作用多）应重写关键部分而非修补。成本评估：对比"修补的原型成本"与"重写+测试+维护成本"，考虑原型缺陷率、可维护性、技术债与长期维护。对高风险/核心代码，重写往往比修补更省总成本。用测试覆盖与接口契约作为重构的锚点。

原型追求的"快速验证"与生产要求的"可靠可维护"冲突，重构成本是决策关键。按原型的可测性/结构评估修补或重写，用测试与契约锚住重构，避免在坏原型上堆代码。

• 密钥注入方式（环境变量/挂载）
• 日志脱敏与遮蔽
• secret 扫描

密钥注入：通过环境变量白名单或只读 secret 挂载注入所需密钥，不把密钥写入 Agent 可见的文件或仓库；Agent 工作区默认不包含密钥，必要时按需注入且最小化。日志脱敏：对 Agent 输出与日志做 secret 扫描与替换，密钥、token 在落盘前脱敏/遮蔽，防止经日志泄露。secret 扫描：定期扫描工作区文件、diff、环境转储，检测硬编码密钥、历史泄露，命中即告警并轮换。三者在采集/写入端落地，保证密钥既被注入使用又不被明文记录。

密钥治理要同时解决"怎么给"与"怎么防漏"。环境变量/挂载最小化注入 + 日志脱敏 + secret 扫描，让密钥可用但不可见、不可外泄，杜绝 Agent 工作区成为密钥泄露源。