【上下文工程/Agent】上下文工程与 Agent 设计的新趋势：

Claude 技术文章：Warp 怎么让 Agent 自己越用越聪明？答案藏在一个双层 Skill 结构里。 Warp 做 AI 终端，他们内部的代码审查 Agent 碰到了经典问题：初版 prompt 大概能完成 80% 的任务，剩下的 20% 产生的错误评论让用户体验很差。团队手动改 prompt、改 AGENTS.md，效果有限——因为人类对 Agent 的反馈，会话一结束就丢了。 他们的解法很简洁：用 Claude Platform 的 Agent Skills 做了个自改进循环。 1. 双层 Skill 架构 Inner skill（基础层）：存功能性的领域知识和指令。比如代码审查 Agent 根据它来做 PR review。 Outer skill（改进层）：一个 observer Agent，不按任务触发，而是定时运行。它拉取累积的人类反馈数据，对比 Agent 做了什么和人类怎么回应，然后提议一条针对 base skill 的小修改。 因为 skills 就是普通文件，Agent 更新它们特别顺手。改动走正常 PR 流程，人审、approve、merge，下一个周期的 inner skill 就继承了改进。 2. Issue Triage 实战案例 Warp 的 triage Agent 给新 GitHub Issue 打标签。第一次跑漏了一个 "ready to spec" 标签——意味着贡献者可以开始做产品和技术规格书。维护者直接在 issue 上留了反馈，说清楚预期什么、为什么这么想。 outer improver 定期跑起来，从 issue 评论区提取了这个信号，生成了一条最小改动，提了 PR 把判断条件加到 inner skill 里。人审 merge 之后，下次 triage 就懂了。 3. 设计原则：写 skill 不是写 code Warp 创始人的建议："当你在教一个聪明的人，而不是编程一台机器。" 与其列一堆硬规则，不如给方向——"Look for repeated code" 比枚举所有命名规则更管用。解释 why，让 Agent 能推理而不只是执行。 反馈必须极低摩擦：直接在 PR 上评、在 issue 上评，不要额外提交步骤。反馈质量远比数量重要，一条资深工程师的详细解释 > 十个点赞。improver skill 本身高度可复用，代码审查的 improver 和其他场景的 improver 差别不大。 4. 最佳实践清单文章最后总结了几条关键教训： 1）别把 skill 和记忆混为一谈。 Skill 是过程性知识——"怎么做 X"，跨 session 稳定，人为主动改。记忆是 Agent 推理时自动写入、永不停止变化的东西。两者机制完全不同。 2）一个 improver loop 够用还是每个 Agent 需要一个？ 折中方案：模板化的 base loop 覆盖共性，叠加领域特异性权重。几个 improver 各自管一个没问题，上百个就该共享。 3）如果人类给了错误反馈怎么办？假设一定会发生。 不要让 Agent 照单全收——给它上下文做 sanity check，过滤谁的意见才算数，要么在过滤阶段、要么在最终 review 阶段保持人在回路。 4）你的领域能不能验证？ 能的话先搭验证 harness，再让 Agent 对着调优：生成参考语料 → 对比输出 → 修复 → 重来。不能验证的话就用确定性 evals 对齐 golden output；用到人工反馈时只限领域专家，别开闸放水。 5）你怎么知道整…

我去，豆包工作居然能领 30 天会员。 作为一个产品经理，不得不说，字节的产品确实做得很好用。 这两天我已经把很多日常的办公任务，都彻底切换到了豆包工作。 用下来几个最戳我的基础体验： 1）轻量，不卡顿。使用门槛非常低。 2）真正的多端互通。而且有云电脑，自己电脑关机也可以用。 3）和飞书做了非常深入的打通。 4）各种各样的连接器，可以打通常用的系统。 5）记忆功能很好，越用越懂我们的喜好。 我之前听一个朋友说过，他会尽量体验这个时代里最新的东西。比如他喜欢开电车，也喜欢尝试各种新出来的软件。原因很简单，这会让他始终和这个时代正在发生的变化保持接触。 我挺认同这个观点。 所以即使你最后不一定长期使用 Agent，我也很建议大家真正体验一下。很多东西只在网上看别人介绍，和自己每天使用，感受完全不一样。 我现在几乎所有的事情，都会先让豆包工作去干。比如下面这张截图，是我直接问它我们业务的问题。 因为豆包工作和飞书已经打通了，所以我飞书中所有的文档、聊天它都可以理解，然后在这