为什么自我进化会把一次错误变成长期风险？
- 注入固化: 网页、邮件和工具输出中的提示注入若被总结成经验，可能跨会话反复生效;
- 恶意工具: 自动搜索的恶意软件包若被封装成工具，影响会从一次沙盒运行扩散到所有后续任务;
- 验证器失守: 一个有缺陷的验证器可能持续批准看似进步、实际退化的待验证版本;
- 结论: Agent 自我进化系统除了验证“是否更强”，还必须限制“谁能改什么、依据来自哪里”;
第一道边界：证据与指令如何隔离？
- 不可信范围: 原始网页、工具输出及其 LLM 摘要都属于不可信证据;
- 两条禁止: 不能当作指令执行，也不能直接纳入 Skill 等长期能力;
- 关键澄清: LLM 总结只是提高可读性和便于处理的转换，并不是把输入变得无害的净化过程;
- 提取规范: 按固定 schema 提取主张、原文位置和采集时间，同时保留原文与来源;
- 执行红线: 提取出的字符串绝不能作为指令执行;
- 置信度边界: 模型给出的置信度也只是未经验证的估计，不能充当批准门槛;
- 发布纪律: 待发布内容需通过确定性的 schema、允许列表和来源检查，再以版本化的 pull request 提交;
- 审查: 独立于生成者的 reviewer 应对照原始证据审查变更，高风险 Skill 上线前还应经过人工批准;
第二道边界：待验证能力与正式能力如何隔离？
- 前置区: 新知识、Prompt、Skill、程序和参数都先进入不可服务真实流量的待验证区;
- 新代码与外部依赖: 还要经过沙盒、权限检查、供应链扫描与行为测试等安全检查;
- 转正条件: 安全检查和回归测试通过后，才能服务真实流量，成为正式能力;
第三道边界：为什么安全机制不能自我修改？
- 可改: 业务 Agent 可以修改 Prompt、Skill、知识库、工具等;
- 不可改: 不能修改批准自身更新的验证器、测试用例、发布门槛、审计日志和稳定版本备份;
- 理由: 否则一个 Agent 只需降低测试阈值或删除失败用例，就能把退化伪装成进步;
- 通用道理: 真正的保证必须来自被修改者无法触及的那一层;
这三道边界与验证闭环是什么关系？
- 分工: 验证闭环回答“是否更强”，安全边界回答“谁能改什么、依据来自哪里”;
- 互补: 缺少安全边界的闭环会把噪声和攻击当作进步;
- 落地: 提案生成者与批准者分离，安全测试与批准规则对提案生成者不可见（见更新能力与受益能力）;