《AI Agents in Depth》学习笔记（五）：Coding Agent 与代码生成

5.1.1 Coding 是每个通用 Agent 的基础能力：七个核心工具#

典型编码任务只涉及五类操作——浏览目录、读取、修改文件、运行命令、查找模式——规范化为七个核心工具：

1. Code Interpreter（代码解释器）：在隔离沙盒（sandbox）中安全执行 Python
2. Bash Shell：执行终端命令（跑测试、处理特殊格式文件）
3. 读文件：读代码、配置、文档、日志
4. 写文件：创建或完全重写文件
5. 编辑文件：局部修改，代码维护与迭代的核心操作
6. Glob：按文件名模式定位文件（如 **/*.py）
7. Grep：在文件内容中搜索文本模式

这是完整而极简的工具箱，均可经 MCP 暴露为标准化服务；它主要覆盖第四章五类工具中的”感知”与”执行”，协作、事件触发、用户沟通通常由 Agent 框架的编排逻辑处理。最小示例：

1
用户：把项目里所有 TODO 注释整理成清单
2
Agent → Grep("TODO", glob="**/*.py")   # 定位 3 处 TODO
3
Agent → Write("TODO_LIST.md", ...)     # 整理写入清单

具备 coding 能力的 Agent 即使只有这七个工具，也能动态扩展能力边界：数学推理交给求解器、业务规则用代码固化、缺工具就临时写一个、数据格式变了就动态生成解析逻辑。

5.1.2 从 Manus 到 OpenClaw：通用 Agent 的 Coding 内核#

Manus 类产品融合 Deep Research、Computer Use、Coding 三大能力；开源项目 OpenClaw 以同样思路展示了这一范式。

为什么 Coding 是核心？几乎所有高效内容生成最终都落到代码：PPT 本质是 OOXML（Office Open XML）代码，Word/PDF 可代码生成，数据分析由 Python 完成，成功的 GUI 操作序列可固化为 RPA（Robotic Process Automation）代码；Deep Research 可由代码驱动的 Web 请求实现；Computer Use 更通用但成本、延迟、稳定性都不如代码或 API。代码生成是效率最高、成本最低、可复用性最强的能力基座。

典型执行流（“分析上季度销售数据并生成报告”）五步：读记忆（MEMORY.md 得知偏好 PDF、数据在 Google Sheets）→ 调工具（搜 API 用法、下载数据）→ 写代码（pandas + matplotlib）→ 生成产物（report.pdf、charts/）→ 更新记忆（记录数据源，下次无需再问）。文件系统是信息流转的枢纽：长期记忆存于 MEMORY.md 与按日期归档的 Markdown 日志。选 Markdown 而非向量数据库看似反直觉实则有效——用户可直接阅读修改记忆（记错就删那一行）、天然保留时间顺序避免语义检索的时间混淆、可用 Git 版本控制与回滚。

5.1.3 Sessionless 设计#

Sessionless（无会话）：无安装、无登录，Agent 常驻在线，用户在既有消息平台发一条消息即得响应。前提是大模型已成熟为”智能基座”——如操作系统屏蔽硬件，大模型屏蔽了语言理解与思考规划的复杂性。

真正的工程难点是代码执行环境和文件系统状态如何跨消息存活（沙盒依赖、工作目录、环境变量、后台服务、写一半的文件）。OpenClaw 分两层：文件系统状态天然持久——工作区挂载在沙盒之外的持久存储上；进程状态按需保活或重建——活跃期保活避免冷启动，闲置超时销毁，销毁前把可序列化状态（工作目录、环境变量、后台任务清单）写入工作区文件，唤醒时按记录重建。代价：每条消息都要重新加载完整轨迹与工作状态，对状态序列化与轨迹压缩要求更高。

5.1.4 Coding Agent 的安全#

叙事线：威胁模型 → 隔离兜底 → 执行期防御 → 信任与忠诚。

单靠输入过滤挡不住提示注入；重点是让 Agent 即使被注入也没机会把危险动作真正执行出去。同一上下文中的 Agent 很难自证清白，关键操作必须由上下文之外的机制复核。本章在第二、四章防御体系上补三点增量：命令语义解析、沙盒与网络出口控制、持久记忆防线（写入长期记忆的内容需经与外部内容同等的信任审查）。

沙盒工程选型四项（隔离分级谱系见第四章）：

• 网络出口控制：最易忽视却最关键——默认断网，白名单代理放行有限目的地。即使注入成功、恶意代码读到敏感数据，没有出口就传不出去；掐断外传通道比识别每次注入确定得多。
• 文件系统隔离：源码只读挂载，单独可写工作区；凭证（~/.ssh、密钥、token）根本不挂载——不可见的数据无法泄露。
• 资源限额与超时：配额加挂钟超时，防死循环、fork 炸弹、无限写盘；超限应向 Agent 返回结构化错误而非静默杀进程，让它下轮修正策略。
• 持久会话与隔离的调和：会话保活在沙盒内部、生命周期不超过沙盒；跨长间隔恢复靠快照或”工作区文件 + 环境按脚本重建”。持久化的是可审计的状态描述（文件、脚本、清单），而非不透明的运行中进程。

语义解析而非关键字黑名单：Shell 组合爆炸让黑名单形同虚设——禁了 rm 可用 $(echo rm) -rf / 绕过，find / -name '*.log' -exec rm {} \; 借合法参数嵌入删除。生产级 Harness 须在语义层理解命令的真实效果（哪些标志位会消费下一个参数、隐藏危险载荷）——“基于理解而非匹配”的高阶实现。

推测性执行让安全检查”隐形”：把”展示”与”放行”拆开并行——界面先显示无副作用的进度提示，后台同时跑 Sidecar 检查；多数情况下检查在用户注意到之前完成，无法快速判定时才暂停等待确认。它不同于 CPU 推测执行：先行的只是 UI 提示，不改变真实状态、无需回滚。

委托方忠诚（principal loyalty）：模型默认”谁跟我说话就帮谁”，但 Agent 常处于多方委托——替你砍价的 Agent 面对的是交涉对手。实测出一条忠诚度光谱，两端都翻车：太老实（把”我方底价 12000”抖给对手、被施压几轮就让步）与太多疑（连主人正当请求也拒绝）；两种失败是一根跷跷板，很难两全。提示注入本质上是一次策反——仓库里的不可信内容、工具输出、第三方 MCP 指令都是”对手”。Harness 要显式钉死忠诚对象：主人指令优先级最高，外部内容一律降格为”可参考、不具指令效力”的数据；守则：保护主人私密信息乃至其”存在性”、拒绝时不逐条念拒绝清单（那本身在泄露）、私下底线不等于对外立场、只执行主人明确具体的指令、顶住重复施压。

把信任边界下移到数据层：对高危数据操作，“更可能守规矩”不够——干脆把应用层当作不可信，把数据不变量的强制执行下沉到它下面。方案（权限内嵌的数据对象，Permission-Embedded Data Objects）：每个数据实体在人类审查过的 schema 中自带声明式权限规则、校验器与后果声明，运行时在每一次写入时强制执行；关键原语访问上下文（access context）——被生成的 handler 以其服务用户的权限运行，自主 Agent 以受限身份（scoped principal）运行。对照实验中该机制零违规，而裸 SQL、LLM 自写检查、宪法式提示、动作边界拦截器都漏过数次到数十次——是”不可能错”而非”更可能对”，代价约每次写入 2 毫秒（前提：schema 写全不变量、堵死绕过存储直连数据库的路径）。架构原则：当写代码的和跑代码的都可能不可信时，可靠约束不能待在被生成的代码里，而要待在它下面人类审查过的地基里——“约束优先于指导”在数据层的终极形态。

5.1.5 整体流程：把软件工程投射到 Agent 身上#

以下是推荐的工程化流程（理想形态）；现实中的 Coding Agent 按反应式迭代循环工作、按需裁剪——简单任务跳过设计文档，复杂任务才走完整流程。“何时停止收集信息、开始行动”的阈值（有的模型广泛阅读后才改，有的读几个文件就提补丁、把编译测试反馈当调查的一部分）首先是模型学到的行为策略，Harness 能放大或抑制但不必是其来源。

1. 项目文档化：首次接触仓库先建立认知框架；关键文档缺失时主动文档化——知识显式化是高效协作的前提。Agent 专用形态是项目指令文件（CLAUDE.md、AGENTS.md、.cursorrules）：每次会话自动注入，相当于项目级系统提示词，承载构建测试命令、代码风格、明确禁区等行为约定，也是最经济的稳定前缀（KV Cache 友好）。推论：对远程工作友好的团队往往也对 AI Agent 友好——远程团队被迫文档化的知识恰是 Agent 能消费的形态；“AI-ready”的代理指标：远程新人只靠仓库和文档能否独立开展工作。
2. 任务理解与需求澄清：简单需求直接实现；复杂需求（需求模糊、路径多样、影响面广）先探索性调研、必要时与用户对话澄清目标与权衡，否则大量返工。
3. 编写设计文档：回答改哪些模块及原因、什么方案、新依赖、预期影响；迫使 Agent 编码前在概念层验证方案，也给人类高效介入点——审设计文档远比审数百行代码容易；批准后再继续。
4. 实现与测试：遵循规范、复用现有抽象；实现后立即写测试（正常、边界、异常）并执行，失败则分析-修复直到通过——这个自我纠错循环把 Coding Agent 从代码生成器提升为可靠工程助手；测试通过后还要自我代码审查（lint 或代码审查子 Agent）。
5. 文档同步：架构级修改要同步更新文档——过时的文档比没有文档更糟。

原则：计划先于行动，验证贯穿始终，文档与代码共同演化。

5.1.6 Harness 工程在 Coding Agent 中的实践#

Coding Agent 是 Harness 工程收益最大的领域——代码是所有 Agent 任务中可验证性最高的一类。能否稳定运行往往不取决于模型多强，而取决于基础设施多扎实。Harness 落地为四组件：验收基线（测试套件、CI、审查标准）、执行边界（模块边界、依赖规则、权限）、反馈信号（Linter、测试结果、类型检查）、回退手段（Git、沙盒、快照）。

用任务清晰度与验证自动化两个维度划分四象限（表 5-1），Harness 的目标是把任务推向”目标明确 + 验证自动化”：

重要结论：Coding Agent 成熟度最高，不是因为代码生成模型特别强，而是软件工程几十年积累的基础设施（测试、类型系统、版本控制）天然构成了强大的 Harness。

业界三例：大规模代码迁移（知识必须存在于代码库本身、约束编码进 Linter 和 CI 而非文档、验证纠正全链路自动化）；LangChain（仅优化 Harness 就显著提升基准表现，并用”Agent 分析失败轨迹改进 Harness”实现数据驱动）；Anthropic（初始化 Agent 分解任务清单 + 执行 Agent 逐步推进并留下中间成果，解决长任务”一次想做太多”或”过早声称完成”）。

工具编排的故障边界控制：故障只在同一批并行调用内传播，不上升到父级——同时读三个文件、一个找不到，只报告那一个，不取消另外两个，更不中止整个任务。

5.1.7 故障与错误恢复#

故障分类学（四层）：API 层（限流 429、过载、超时、连接中断、输出截断——与任务无关的基础设施噪声）；工具层（幻觉调用、参数畸形、执行异常，以及最危险的”工具反复返回同一错误而模型不加改变地重试”）；上下文层（窗口溢出、压缩失败、轨迹结构损坏）；控制流层（死循环与死亡螺旋——错误触发的恢复逻辑自身又调 LLM、再出错、连锁反应）。

检测：先分类，再计数。第一个判断不是”要不要重试”而是”值不值得重试”：可重试（限流、网络抖动）与不可重试（参数不合法、权限不足、工具不存在——必须改变输入或策略）；生产级 Harness 维护”错误 → 恢复策略”映射表。模式层面：重复调用指纹（“工具名 + 参数”指纹反复出现即无进展循环）与每条恢复路径独立的连续失败计数。流式连接最危险的不是断开而是静默卡死（水管通着但不出水；SDK 超时常只覆盖初始连接），需独立的空闲看门狗（watchdog timer）——原则：每个长连接都需要活性信号。完整性监控在注入上下文前自动修复缺配对的工具消息；值得注意的双重标准：“产品模式宽容（占位符修补）、训练模式严格（拒绝修复——合成占位符会污染训练数据）”。

恢复：分级升级，逐级透明：(1) 静默重试——指数退避加随机抖动、尊重服务端等待提示；辅助性后台调用（标题生成等）失败直接放弃，避免”重试放大”挤占主链路配额；(2) 降级与接续——改变请求本身：输出触顶先提升上限重发、再追加元指令从断点接续；主模型过载降级备用模型（先剥离旧模型私有格式块）；(3) 暴露给用户——自动手段用尽才呈现，并附已尝试的恢复动作。工具层错误另走一条路：不终止会话，把错误变成模型的输入——结构化错误进入上下文由模型下轮自行纠正，喂回的错误越具体成功率越高。核心原则：错误处理的边界不是单次请求，而是整个恢复循环——确认无法恢复之前，中间错误不暴露给消费者。

终止：每条恢复路径都要有熔断上限，阈值来自产线数据：Claude Code 压缩熔断”连续 3 次”的依据——曾有会话在该路径上连续失败三千余次，这类无效重试每天全球浪费约 25 万次 API 调用，逾千会话出现过 50 次以上连续失败；3 次是”绝大多数故障已恢复”与”继续基本无望”的经验拐点。死亡螺旋的真实案例：上下文溢出 → 触发”结束时自动提交”钩子 → 钩子调 LLM 生成 commit message → 再次溢出 → 再次触发；防护两条：错误路径上禁用一切会再调模型的副作用逻辑（宁可丢一次辅助功能），递归深度计数器打断残余连锁。之上还有全局条件：最大迭代轮数、会话预算上限、连续失败升级人工。

5.1.8 实现技巧#

五个相互配合的技巧，让 Agent 像经验丰富的开发者那样流畅工作：

1. 并行工具调用、流式执行与级联中止：第一个工具调用的参数一经完整并通过校验即可执行，与后续调用的生成重叠；独立调用并行执行。工具需声明是否支持并发（默认否，失败安全）；失败时级联中止同批依赖调用，不波及独立调用与父级。
2. 上下文精细化管理：大文件按行号范围读取片段；返回内容附行号前缀——模型可精确引用”第 42 行”，让后续编辑更可靠；终端长输出保留首尾若干行，中间以提示替代并注明完整输出已存临时文件。
3. 环境信息动态注入（Agent 状态栏）：每次推理前注入当前工作目录、git 分支、最近提交、暂存/未暂存变更概览；不硬编码进静态系统提示词（破坏 KV Cache），而作为动态追加式状态栏。
4. 命令执行环境状态持久化：维护持久终端会话，保留工作目录、环境变量、虚拟环境、后台服务，避免每条命令都在全新 shell 中重来；保留隔离终端支持并行任务，但持久会话是默认模式。
5. 即时语法反馈：文件写入一完成，工具层自动跑 linter/语法检查并把结果并入工具返回值——像 IDE 打错括号立刻画红线，在错误引入那一刻修正。

5.1.9 搜索工具：四种互补方式#

建不建嵌入索引的路线之争：Claude Code 等终端型 Agent 刻意不建索引，纯靠 agentic 的 grep + glob 现场检索——不维护随代码演化而陈旧的索引、省掉索引基础设施、避免代码嵌入外发第三方；Cursor 等 IDE 型工具则愿为跨文件语义召回付出建索引的成本。本质是”基础设施与数据外发的代价”对”跨文件语义召回的收益”的权衡。实践中组合使用：先语义搜索找模块，再正则精确定位，最后符号搜索追调用链——从粗到细、从语义到语法。

5.1.10 文件编辑工具：五种方案#

难点不在操作本身，而在如何让 LLM 高效又可靠地表达”改哪里、怎么改”——人类语言表达与机器精确执行的根本张力。

实践建议：自建 Agent 以”旧字符串 → 新字符串”为最稳妥起点；大段改动用”首尾匹配”更经济；行号方案仅在 IDE 深度集成（实时维护行号映射并即时供给模型）时才可靠。

5.2.1 代码作为思考工具#

模型思考本质是概率性、近似的，而数学与逻辑要求确定精确：

1
问题：40 名学生，60% 选数学，45% 选物理，25% 两门都选，只选物理的有几人？
2

3
纯自然语言推理（易错）：              代码推理（精确可验证）：
4
"只选物理 = 24 - 10 = 14 人"          phys = int(40 * 0.45)   # 18
5
→ 误从数学人数中减，答案错误           both = int(40 * 0.25)   # 10
6
                                      print(phys - both)      # 8 ✓

分工：LLM 理解问题并写代码，解释器负责精确计算。Wolfram 的洞察揭示互补性：符号计算（Symbolic Computation，保持 √2 的精确形式而非近似为 1.414）系统如 Wolfram Alpha 计算精确但自然语言理解脆弱、覆盖窄；LLM 恰好相反。协同模式：LLM 把自然语言转化为形式化语言（Mathematica、SymPy），交给符号计算引擎或约束求解器执行。

实验 5-1（★★）：sympy/numpy/scipy 沙盒解 AIME 风格数学题，代码辅助显著高于纯思维链。实验 5-2（★★）：python-constraint 解”骑士与无赖”逻辑谜题，K&K 数据集上代码辅助准确率 90% 以上。后者还揭示一条普遍规律：模型与脚手架此消彼长——模型足够强时脚手架可以更薄（求解器增益收敛到近零）；模型不够强时就要靠代码和约束求解器兜住正确性。同一套脚手架配不同能力的模型，结论可能截然不同——评估 Agent 技术时最易忽视的前提。

5.2.2 代码作为业务规则的约束#

自然语言规则充满歧义：“7 天内可退款”——自然日还是工作日？“购买”是下单还是发货？代码要么运行要么抛错，无模棱两可。两者互补而非替代：提示词中的自然语言规则供模型解释政策、寻找变通（“改签而非取消”）、调用前初判；代码化校验提供精确性与确定性，适合复杂规则组合。代码化的真正价值不在省 token，而在防止不可逆的错误操作（取消订单、转出资金、删除数据）——安全保障价值远超实现成本。

推荐合并校验与执行，以 τ-bench（模拟航空/电商客服、评测工具调用与政策遵守的基准）的取消政策为例：

1
def cancel_reservation(
2
    reservation_id: str,
3
    cancellation_reason: str,
4
    expected_cabin_class: str = None,    # 可选：模型自查用，服务端以数据库真值复核
5
    expected_has_insurance: bool = None  # 可选：同上
6
) -> dict:
7
    """
8
    取消航班预订。取消政策（服务端根据数据库真值强制执行）：
9
    规则1 已使用任何航段不可取消；规则2 预订 24 小时内可无条件取消；
10
    规则3 航司取消的航班总可取消；规则4 商务舱总可取消；
11
    规则5 （基础）经济舱需购买旅行保险才可取消。
12
    调用前请先查询订单详情逐条核对；expected_* 仅供服务端比对与审计，不影响裁决。
13
    """
14
    # 所有政策事实一律从数据库读取，绝不采信模型自报的值
15
    r = db.get_reservation(reservation_id)
16
    now = server_clock.now()  # 服务端时钟，而非模型提供
17
    if expected_cabin_class is not None and expected_cabin_class != r.cabin_class:
18
        log_mismatch(...)  # 自报值与真值不一致 → 告警（发现错误认知或潜在注入）
19
    if r.any_segment_used:
20
        return {"success": False, "reason": "Cannot cancel with used segments"}
21
    if (now - r.booking_time).total_seconds() / 3600 <= 24:
22
        execute_cancellation(reservation_id)
23
        return {"success": True, "reason": "Cancelled within 24-hour window"}
24
    ...  # 规则 3/4/5 同理：全部基于数据库真值判定

两层价值：第一层，参数作为思考的 checklist——为填 expected_* 参数，模型必须先查订单逐条核对政策；查到经济舱未购保险时很可能根本不发起调用，而是直接向用户提议替代方案。这层引导思考、减少无效调用，但不承担安全责任。第二层，服务端真值校验才是守门员——舱位、保险、时间、航段、航班状态全部由服务端查库获得，没有任何一条政策事实来自模型自报的参数；若关键事实由模型填写，模型报错（或被诱导报错）一个值，守门员就形同虚设。

实验 5-3（★★）：小模型（Qwen3-4B）+ 三重保障对纯自然语言规则的对照，指标含成功率、政策违规次数、无效调用次数及自报值与真值不一致比例。

5.2.3 代码驱动的多媒体生成#

复杂文档本质是结构化数据的组织呈现，底层由代码定义（HTML/CSS/JS、PPT 的 OOXML）。GUI 所见即所得对 Agent 不友好（需视觉理解与坐标定位）；代码生成绕开视觉定位，获得程序化的精确控制。

PPT 生成：Slidev 等框架用 Markdown/HTML 定义演示内容，对 Agent 极友好。但 Agent 写完代码并不知道实际渲染效果（内容挤不挤、文字是否溢出），因此引入提议者-审核者（Proposer-Reviewer）机制：Proposer 生成 Slidev 代码；Reviewer 运行代码把每页渲染为图片，用 Vision LLM 从内容密度、可读性、布局、美感维度分析，产出结构化改进建议（含页码、问题类型、严重程度，如”第 3 页内容过多建议拆分”）；迭代直到质量达标或达到最大轮数（如 5 轮）——正是 Loop 工程的两类显式终止条件。

它与第四章事前审批同属提议者-审核者范式（生成与审查分离、双模型独立评估、不同模型家族降低同类错误概率）；差异：安全审查是单次批准/否决，这里是多轮迭代，且审核者接触到提议者看不到的新信息（渲染结果）。双 Agent 分工的核心优势在上下文管理：Reviewer 只看最新渲染图，Proposer 只累积结构化文本反馈；单 Agent 要在同一上下文累积数十页渲染图的多轮迭代，迅速超限。

视频编辑：剪辑软件 GUI 极复杂（时间轴、图层、坐标定位难），重构为 API 调用 + 代码生成后大幅降维——Blender Python API、FFmpeg 以结构化方式暴露核心功能；同样用提议者-审核者（Proposer 生成 Blender 脚本，Reviewer 渲染关键帧交 Vision LLM 检查）。实验 5-4（★★）论文自动生成 PPT；实验 5-5（★★）继而生成讲解视频（口语化讲解词 + TTS + ffmpeg 同步合成，5-15 分钟、画面与语音精确匹配）；实验 5-6（★★）智能剪辑——两步定位：先每 10 秒截图粗定位场景区间（“冲浪在第 40-110 秒”），再在窄范围内每秒截图精定位边界（起止误差不超过 3 秒）；视频分析封装为子 Agent，避免大量截图挤占主 Agent 上下文。

5.2.4 代码作为系统适配器#

前几节的代码面向”人”，这一节面向机器与机器的连接。外部服务常无 SDK、接口不规范（文档缺失、返回非标、字段随版本漂移），Agent 现场读接口文档或观察一两条真实响应，即时生成适配代码：构造 HTTP 客户端、拼装鉴权头、解析非标结构、翻译数据模型——代码是连接任意系统的”万能胶”。还能延伸到完全没有 API 的系统：先用 Computer Use 操作界面，再把成功的操作序列固化为 RPA 代码——未来直接运行代码，无需再调用昂贵的视觉思考（“工作流录制与固化”见第八章）。

日志自适应解析（实验 5-7 ★★★）：前端遇到无法解析的日志格式时不显示错误，而是自动把失败信息（原始样本 + 报错）报告给 Agent → 生成解析代码 → 虚拟浏览器自动测试（Vision LLM 检查可视化）→ 热更新部署——自我进化的反馈循环，系统自动适应格式演化。

日志自动诊断（实验 5-8 ★★★）：Agent 读生产轨迹（trajectory），结合架构文档和 PRD 判断执行是否符合预期、定位问题模块 → 生成结构化问题报告（优先级、模块、描述、建议）→ 自动生成回归测试用例（引用轨迹 ID 与交互轮次，框架自动重放验证修复）→ 经 MCP 对接 GitHub 自动建 Issue 分派——从问题发现到任务分派全自动化。

5.2.5 代码作为生成式 UI#

纯文本对话线性单一：收集结构化信息要反复问答、复杂数据关系表达力有限、多选项不如可视化直观。生成式 UI（Generative UI）：Agent 动态生成表单、交互图表甚至完整 Web 应用。

A2UI 类协议：Agent 直接生成 HTML/JS 有根本安全问题——提示注入可让它不知不觉生成窃取数据的脚本（成因是提示注入，效果类似传统 XSS，但不能把整个攻击直接叫 XSS）。A2UI（Agent-to-User Interface）等声明式协议：Agent 只输出 JSON”界面描述清单”，客户端用预备好的安全组件渲染——像餐厅菜单：Agent 只能点菜单上的菜（受信组件目录：Card、Button、TextField、Table），不能进厨房自己做（执行任意代码）。特性：安全优先、跨平台（同一描述在 React/Flutter/原生渲染）、增量生成（流式 JSONL 边收边渲染）。易混淆：AG-UI（CopilotKit）不是界面描述语言而是事件/传输协议（把消息、工具调用、状态补丁流式推送前端，可承载 A2UI 载荷）——互补而非同类。声明式适合标准化交互（表单、表格、卡片）；高度定制需求仍需直接生成代码。

用 HTML 交付成果，取代 Markdown 汇报：三优势——交互式演示（一看就懂）、更好的数据可视化（图表 + 可筛选下钻的交互组件）、可持续完善的活文档（随工作推进不断更新）。作者实践：每个研究项目维护一个交互式网站，承担实验数据追溯（逐条查 prompt 与 LLM 原始回复，易发现数据问题与 judge 的系统性偏差）、训练内科指标监控（借医学之喻：损失、梯度范数、学习率、困惑度、RL 的奖励/KL/策略熵等过程信号，比结果指标更早暴露训练问题）、运行原理可视化。

澄清用户意图：文本问答十个澄清点要十轮，级联依赖难表达。Agent 生成动态 HTML 表单：文本框、下拉、复选、日期选择器，JS 级联逻辑（选”往返”才显示返程日期），一次填写完成（实验 5-9 ★★）。

生成 SQL 与 Artifact 模式：让 Agent 读查询结果再复述看似”智能”实则低效——数千行结果耗费大量 token，且 LLM”抄写”数据极易出错。更好的是 Artifact 模式：Agent 只生成 SQL 作为独立的可执行产物（artifact），系统直接执行并渲染成表格——数据从数据库直达用户界面，完全绕过 LLM 这个”中间人”。安全前提：只读账号、仅允许批准的 SELECT（拒绝 DDL/DML/多语句）、服务端参数化绑定、限制时长/行数/可访问表、可视化代码在隔离沙盒运行——Artifact 缩短数据路径，但不能替代权限检查与执行隔离。进一步可生成”SQL + 可视化代码”两个 artifact 组成流水线，前端把结果直接传给可视化代码——代码生成作为接口的精髓（实验 5-10 ★★：自然语言交互的 ERP Agent，在 PostgreSQL 员工/工资表上回答十类统计问题）。

动态生成软件：Anthropic 的”Imagine with Claude”展示完全动态生成软件的能力边界（实时生成界面与交互逻辑），但成本延迟高；更务实的是基于已有框架的半定制：用户说”按钮改蓝色""侧边栏加菜单”，Agent 修改前端代码，热加载（HMR，Hot Module Replacement）即时生效——把”一刀切”产品变成”千人千面”（实验 5-11 ★★：React + FastAPI 对话式界面定制）。

5.2.6 代码创造代码：Agent 自举#

本节讨论 Coding Agent 用代码修复和创建同类 Agent——自我修复、自我复制、按需生成新 Agent，称为自举（bootstrapping）；第八章则讨论何种生产经验应触发自我修改、候选版本如何经回归/灰度/回滚上线——两章在”修改代码”处相交，回答的问题不同。

自我修复：OpenClaw Doctor。doctor 命令自动检测三类问题：配置异常（过期 OAuth token、遗留配置格式、端口冲突）、状态问题（陈旧会话锁、插件依赖缺失）、服务健康（网关未运行、沙盒镜像缺失）；分层修复——安全的修复自动执行，有风险的操作（服务重启、强制覆盖配置）需用户确认。避免夸大：高频问题以确定性检查先覆盖（与传统运维脚本无本质不同）；真正体现 Agent 能力的是第二层——规则未覆盖的疑难交给 LLM 分析错误日志、理解配置语义、推断因果生成修复方案。当工作对象是自身运行环境时，自我修复就从系统适配器升级为自举的基础设施。

让 Agent 编写 Agent：缺乏领域知识时，最强的模型也会产出四类架构缺陷——上下文管理随意（轨迹转纯文本、忽略结构化消息的 KV Cache 优化、循环边界 bug）；工具设计不规范（描述简略、缺使用边界与负面清单、参数无示例）；技术选型滞后（倾向用训练数据中常见但已过时的模型与 API，解法是维护 SOTA 知识库或赋予搜索能力）；外部生态脱节（废弃 API、弃维护的库）。

实验 5-12（★★★）：构建具备元编程（Metaprogramming，编写能生成或修改其他程序的程序）能力、能创造 Agent 的 Agent，对比”从零生成”与”基于范例修改”的质量与效率。自举是代码生成的终极应用——能创造 Agent 的 Agent 实现了智能的自我繁殖。