【上下文工程/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）你怎么知道整…

🔥 MCP、ACP和A2A三种协议的无偏比较 随着AI系统从单一模型向工具和代理网络的演变，三种关键协议正浮出水面： ✅/ MCP（Anthropic）：通过工具/资源扩展模型能力 ✅/ ACP（IBM）：具有MIME支持的REST原生代理间协议 ✅/ A2A（Google）：具有任务级记忆的有状态代理消息传递 MCP和ACP/A2A听起来相似，但它们解决非常不同的问题。 TL;DR（太长不看）： 使用MCP用于模型工具链。 当代理需要交谈、协作和记忆时使用ACP/A2A。 ‼️ 你可能两者都需要。 根据您提供的表格图片（浅蓝色背景，标题行稍深），以下是MCP、ACP和A2A协议的详细对比。图片中还建议了每种协议的使用场景：MCP适合模型扩展工具链，ACP适合代理交互开发，A2A适合复杂任务协同。 📌传输与通信 ✅MCP：使用JSON-RPC与stdio（本地）或HTTP+SSE/Streamable HTTP（远程）。远程系统上的RPC风格方法调用。 ✅ACP：RES