AI Agent 开发课

模型每次前向只是「给定 context 预测下一个 token」,两次调用之间什么都不保留;所谓对话记忆、平台记忆功能,本质都是把内容重新喂进 context(A、C 错)。温度只影响采样随机性,与记忆无关(D 错)。推论:① 状态管理是你的活;② context 窗口是硬预算;③ 历史应 append-only 以吃到 prompt caching。

A 的路径可以预先枚举:读文件→聚合→渲染模板→发送,写死代码比 agent 便宜、快、稳定得多。B/C/D 的共同点是路径无法预先枚举(要探索、要根据中间发现改变策略),才值得付出 agent 的不确定性和成本。「能 workflow 就别 agent」。

核心收益是把编排开销(每步一次模型往返的延迟+token)压掉,且表达力更强(临时变量、批处理、条件分支)。代价恰恰是 C 的反面——执行任意代码攻击面陡增,必须配沙箱;且一步大代码块里错误定位更难。A、D 与事实不符。

要点:工具集小而正交 + 破坏性操作可逆化(trash 而非 rm)。A 攻击面和失误面都最大(rm -rf 事故就是这么来的);B 的 schema 挤占 context、功能重叠让模型选择困难;D 过度保守,自动化价值归零。C 还便于设置人批点:批量删除超阈值才需要确认。

A、B 都是模型自我报告,系统性偏乐观(过早宣布完成是最常见失败模式之一);C 是兜底预算不是验收标准。只有 D 以环境末态为准、与路径无关,最可靠——所以设计任务时第一问永远是「验证器是什么」。生产系统通常 A+C 兜底、D(或独立 evaluator)把关。

错误是养料:模型看到具体报错通常能自愈(改路径、换命令、装依赖)。例外才需要处理:报错超长要截断摘要、含敏感信息要过滤、同一错误重复 N 次要升级策略而不是继续撞墙。A 浪费轮次且丢失信息,B 剥夺自我修正机会,D 过度保守。

rot 不是硬故障(A、D)也不是成本问题(B),而是「窗口还装得下,但注意力已经稀释」。agent 场景更严重:每轮工具输出自动堆积、错误输出会被后续当事实引用形成自我污染、任务目标恰好在最容易被忽略的开头位置——所以长任务会「忘了初心」。

判据是使用频率×体积:每轮都要用且体积小的(行为规范、任务描述、核心 API 签名)预载;大而低频的(A/B/C)给检索工具按需拉取,预载它们就是纯浪费注意力预算。趋势正是从「RAG 预载」转向「agentic search 按需」。

D 完全是错的——推理时权重永远不变,这正是模块 1 第一条心法。todo.md 的全部魔力都在 context 层面:A(对抗中段失忆)、B(状态外置到不会丢的地方)、C(结构化自监督)。用最土的文件解决最核心的问题,这就是好工程。

缓存要求前缀逐字不变:system prompt 在最前面,每轮变一个时间戳 = 每轮全量 cache miss,成本立涨约 10 倍。A、C、D 正是吃缓存的正确姿势。Manus 把 KV-cache 命中率列为 agent 最重要的单一指标;compaction 也因此要算账——它本身就是一次全量 miss。

A/B/D 都是「结论已提取、原文可丢」的低信号内容,是压缩的主要对象。C 是 agent 的「身份记忆」——丢了目标就跑偏,丢了决策理由就会反复横跳(把已否决的方案再试一遍),丢了当前状态就重复劳动。好的压缩模板:目标/约束/已做决策+理由/当前状态/待办。

子代理是 context 防火墙:脏活(读原文)发生在一次性的子 context 里,主循环只见结论。A 治标不治本——窗口再大 rot 依旧,且贵;B 是反面教材(预载大量低频内容=稀释注意力);D 不相关。若来源间有依赖需要滚动聚焦,可配合「流水线+外置笔记」混用。

harness 的职责是让模型的智能得以落地(干净环境/好工具/恢复路径),不是替模型思考。A 是最常见的反模式:塞进循环的业务逻辑隐含「模型不会 X」的假设,模型一升级全变累赘、还约束它更优的原生策略。B、D 是无关的字面误读。

B 有自动验证器(测试红转绿+不回归),agent 可以自己跑到绿灯为止,无人值守也不怕——错误会被机器当场抓住。A/C/D 的「好坏」无法脚本断言,只能靠 evaluator 或人把关,自主放行的风险高得多。这也是为什么 coding agent 是最先成熟的 agent 品类。

独立的关键是信息隔离:generator 的 context 里全是「我为什么这么做」的叙事,评估会被带偏——A、C 都还泡在这个叙事里,实证上系统性偏乐观。D 是角色污染:评估者一旦动手改,就变成了新的 generator,又没人评它了。正确回路:evaluator 找茬 → 结论回给 generator 修。

放行策略要分级:低风险(改动小+非核心路径)+ 硬验证(测试绿+不回归+lint 过)+ 软验证(evaluator 审过)三者齐了才自动放行。A 是模型自报,不可信;B 只验证了「修好了这个」没验证「没弄坏别的」;D 过度保守——那样 agent 只是个建议机器,自动化价值大打折扣。敏感路径(鉴权/支付/迁移)永远人审。

harness 每个组件都隐含「模型不会做 X」;模型迭代让假设过期后,组件从助力变阻力(Anthropic 就定期从 Claude Code 删掉被模型内化的规划辅助)。所以要易删(C),而不是焊死(A)、供着(B)或推倒重来(D)。METR 曲线(能力时长约 7 个月翻倍)告诉你这些假设过期得有多快。

这是长任务三件套:初始化定结构、每会话把「完成了什么/踩了什么坑/下一步」写进 PROGRESS、新会话从文件冷启动。Anthropic 明确说单靠 compaction 撑不住真正的长任务——压缩是有损的,压 16 次后目标早就面目全非(A);窗口再大也有 rot 和成本问题(C);D 杯水车薪。关键设计:每个会话都假设自己是第一次来。

模型没有「数据 vs 指令」的类型系统:网页、邮件、文件里藏的指令都可能被当成指示执行——届时执行者拥有的是 agent 的全部权限(你的文件、你的 shell、你的账号)。A 说的是纸面权限,这句话讲的是实际暴露面;C、D 无此机制。防御必须建立在「注入总会有成功的一天」之上。

三角齐了,攻击链就通了:不可信内容(网页/邮件)注入指令 → 指令让 agent 读私密数据 → 经对外通道(发邮件/HTTP 请求/写公开 issue)带出去。防御第一刀是砍一角:通常砍「对外通信」最可行(白名单+人批),或者把「碰不可信内容」和「碰私密数据」拆到两个互相隔离的 agent。

攻击者不同、受害者不同:jailbreak 里攻击者=用户自己,危害主要是模型说了不该说的;injection 里攻击者是第三方内容的作者,受害者是 agent 的主人。injection 对 agent 更根本:agent 的本职就是读不可信内容+持有真实权限,而模型至今无法可靠区分数据和指令——所以防御必须在系统层。

容器共享宿主内核,逃逸面是整个 syscall 界面,对「完全不可信」不够;microVM 每个沙箱独立内核、靠硬件虚拟化隔离,攻击面小得多,Firecracker 还能 <200ms 冷启动即用即抛(E2B 的方案)。A 更弱;D 是用提示词做安全,不成立。注意分级:跑「自己 agent 写的、自己看过的」代码,容器+网络白名单通常是性价比之选。

一句静态告诫 vs 无限的攻击变体(角色扮演/编码/多语言/分段拼接),这是不对称战争——防成功率 99% 都不够,因为攻击者只需成功一次。结构性方案:污点隔离(CaMeL:不可信数据永不进控制流)、能力限制、出口管控(白名单+人批)、计划锁定、沙箱兜底。核心思想:假设注入一定成功,设计成「成功了也没事」。

A 管死对外通道(砍第三角)、B 结构性拆分让注入无法跨界携带指令、D 降私密数据暴露(砍第一角)——都是系统层的有效手段。C 是提示词对抗提示词,上一题已经说明为什么不可依赖:它可以作为纵深防御的点缀,但绝不能作为方案本身。

同一任务有无数条正确路径、无数种等价产出(一个 bug 有 N 种改法),比对文本必然误判;假阳性尤其致命——它系统性奖励糊弄。执行式验证只断言末态(测试绿/文件对/数据库对),路径无关。A、D 说反了(搭执行环境其实更贵更慢,但值得);C 与已知事实相反(裁判有偏乐观和位置偏差)。

C 是「大而假」:别人的任务测不出你的场景,没有验证器的题只能人工判分,量大到跑不起、更看不过来失败轨迹。正确姿势还包括:任务分层(冒烟必须全对 + 能力边界 50% 通过率最有信息量 + 少量 stretch)、环境可重置、任务描述冻结。10~20 个高质量任务足够指导迭代。

8 次里至少 1 次能成 = 模型「会做」,单次 60% = 方差大,这通常是 harness/反馈问题而非能力问题。利用:① 有自动验证器就跑 k 次挑对的,60%→95% 只花 k 倍成本;② 修 harness(更好的错误回填/验证闭环)往往比换模型便宜;③ 反过来,产品化 agent 要盯 τ-bench 式的 pass^k(k 次全对,考一致性)——用户不会给你跑 8 次的机会。

50% 通过率附近的任务信息量最大——harness 一改,分数立刻可见变化;全绿(A)测不出退步以外的任何东西,全红(B)测不出进步的方向,凑数(C)看不过来失败轨迹。冒烟守底线(它挂了=有东西坏了),stretch 当进度条(哪天过了=能力跃迁)。做完后自检:故意改坏 harness 一处,分数应可检测地下降——这证明 eval 有分辨力。

归因顺序不能反:① 先查任务本身(验证器写错/描述歧义/环境没重置)——这占比高得惊人,SWE-bench 都因此出了 Verified 子集;② 再查 harness(缺工具/错误没回填/context 爆了)——症状是「思路对但执行卡壳」;③ 都排除了,换最强模型重跑还挂,才能定罪为能力边界。A/C/D 都是跳过诊断直接开药。