Agent 自举

Agent 自举需要什么前提能力？

• 问题: 把代码生成能力推向极限后自然出现——Agent 能不能用代码生成能力创造另一个 Agent;
• 前提: 自我修复能力——Agent 的工作对象不再是外部系统，而是它自身的运行环境;
• 定位: 自我修复从系统适配器升级为 Agent 自举的基础设施;

自我修复如何分层？

• 例证: OpenClaw 的 doctor 命令;
• 问题类别一（配置异常）: 过期的 OAuth token、遗留的配置格式、端口冲突;
• 问题类别二（状态问题）: 陈旧的会话锁文件、插件依赖缺失;
• 问题类别三（服务健康）: 网关未运行、沙盒镜像缺失;

修复层级	处理对象	执行方式
确定性检查	高频、规则明确的问题	安全修复自动执行（配置归一化、锁文件清理）
LLM 兜底	确定性规则未覆盖的疑难问题	分析错误日志、理解配置语义、推断因果关系，生成针对性方案

• 权限分级: 有风险的操作（服务重启、强制覆盖配置）需要用户确认;

为什么不能夸大 Agent 在自我修复中的作用？

• 事实: 过期 token、锁文件、端口冲突这类高频问题本身就有明确的检测规则与固定修复动作，doctor 以一组确定性检查为基础先把它们覆盖掉;
• 判断: 这与传统运维脚本并无本质不同;
• 真正体现 Agent 能力处: 第二层——对规则未覆盖的疑难问题，交给 LLM 分析日志、理解配置文件语义、推断因果并生成修复方案;
• 配合方式: 确定性检查保证常见问题被稳定修复，LLM 兜底应对长尾疑难，doctor --fix 才能自动解决相当一部分常见网关问题;

让模型编写 Agent 的常见缺陷有哪些？

• 缺陷一——上下文管理的随意性: 未采用标准上下文格式，把轨迹转成纯文本塞进上下文，忽略结构化消息带来的 KV Cache 优化，工具调用循环存在边界 bug;
• 缺陷二——工具设计的不规范: 描述简略、缺少使用边界说明与负面清单、参数缺乏具体示例;
• 缺陷三——技术选型的滞后性: 倾向使用训练数据中最常见但已过时的模型与 API;
• 缺陷四——外部生态的脱节: 使用废弃 API、不再维护的库或有缺陷的模式;
• 根因: 创造高质量 Agent 需要对 Agent 架构模式、最佳实践和常见陷阱有深入理解，缺乏该领域知识时最强代码生成模型也可能产出架构上有严重缺陷的 Agent;

为什么基于范例的生成优于在提示词里穷举规则？

• 对策: 最有效的路径不是穷尽所有规则，而是提供高质量的 Agent 实现作为参考范例，引导代码生成 Agent 在此基础上修改，而非从零开始;
• 理由一: 范例代码本身就是最佳实践的载体;
• 理由二: 基于范例修改比从零编写更容易做对，架构上的好选择会自然保留，无需在提示词里逐条说明;
• 操作: 接到开发新 Agent 的任务时，先复制自己的代码（或其他经验证的高质量实现），再针对性修改;
• 修改维度: 调整系统提示词匹配新角色、替换或增删工具适应新功能、修改业务逻辑但保留架构框架;
• 类比: “自我复制并适应性修改”如同生物学中的基因复制加变异——既继承核心技术优势，又允许特定维度差异化;
• 验证结论: 对比从零生成与基于范例修改，后者在生成质量与效率上占优，且生成的 Agent 使用标准消息格式与工具调用协议、采用当前推荐的模型与 API，多轮对话中上下文与状态管理正确;
• 定位: 这是元能力作用在“Agent 自身”这一层，见 代码作为元能力;