阅读笔记 - 2026-03-21
马东锡 NLP：如果要为这周的 AI 发展一个关键词，那就是自主进化。 从 Meta-Evolution、AutoHarness、SkillNet、SkillCraft MiniMax-M2…
要点
- skill craft 可以观察 agent 的调用过程，通过对 agent 调用 tool 的习惯，提取可 reuse 的 skill，这样下次执行这个任务时， agent 会优先调用 skill ，从而减少探索时间
- 我们不需要很多 skill ，而是应该从自己的工作流里面提取
我的观点
- 价值：有一个视频很好的介绍了 skill craft ，这个过程也很有价值。他是面向 agent 的 skill ，帮助 agent 更好的提炼过程。适合那种更复杂，步骤多的流程。其实不适合编程。
- 适用条件：复杂流程的 skill 化优化。
garrytan/gstack: Use Garry Tan's exact Claude Code setup: 15 opinionated tools that serve as CE…
要点
- yc ceo 的工具集，其实就是把 cc 拆分多个角色，执行不同任务
- 从结构上分有：
- think: yc 式产品发现，6个必要的方法论提问
- plan: ceo评审、技术架构评审、设计计划评审（0-10分）
- design：系统架构设计，输出 design.md
- build：基于设计文档使用 cc 编码
- review: 正常 review ，自动修复+标记问题， codex review ，交叉评审， investigate 根因调试，深挖问题源头
- test: qa浏览器调试+修bug， qa-only 只汇报不修改，design-review 真机的设计评审+修复
- ship：ship：跑ci测试，推代码，开 pr ， document-release 自动更新文档
- reflect： retro 周报统计，拆开细的维度
- 工具层： careful， freeze, guard, browse
我的观点
- 价值：其实就是一套很正常但全面的 ai 工具集，里面的一些提问方式可以学习过来
- 适用条件：没必要全抄，但是一套有价值的 agent 实践
实践哥MinLi：你搭的 Claude Skills，还能提升10倍效果——使用Karpathy 的 autoresearch 方法 【译】
要点
- 作者发现自己的 skills 没有一个客观评价标准，交付客户后质量不行，需要有客观的评价体系和优化体系
- 作者使用 autoresearch 来做这个事情，能达到不错的效果
- 这个体系还可以用来优化那些模糊评价的交付物，如设计、性能指标、市场文案等。
方法
- 使用 autoresearch ，给他一个 skills 和多个对质量评价的 checklist ， autoresearch 会自动尝试优化（5-6个问题最好，多了以后会过拟合）
- 保存下 changelog ，下次有更好的模型出来后，可以用更好的模型来优化他
- 这个方法也可以用于其他的，比如网站性能，网站设计优化，或者宣传内容生成器
我的观点
- 价值：一套实践方法论，其实就是人因工学的那套，通过某种客观标准，然后利用 ai 对其进行演化。 autoresearch 可能是这个体系的核心，但我认为也不是必然的。他更多的是分享了一种观点：很多主观的东西都可以用客观标准+自我演化的方式进行调优。
- 风险：其实 agent 在初始时自动问的问题的质量对后续演化的可能性的影响最重要。 autoresearch 能否做到高质量提问？这才是最核心的问题。其次这个作者的交付物是 skills ，其实是一个相对简单的交付物，如果是复杂一点的东西，如研究报告或工作流，是否还能有这样好的交付效果呢？
- 适用条件：有客观评价 checklist 的体系，可以做人因工学的研究方向，适合这个工具
Tw93：你不知道的 Agent：原理、架构与工程实践
要点
- 一篇长文，手把手的教你如何构建一个 agent ，不是 workflow 那种固定流程的，而是由 llm 自主决策工具调用的 agent 模式。手把手的教你如何优化工具调用，评估执行结果，保持记忆，用 openclaw 的例子教你怎么做大型的 agent 应用
- agent loop 就是4个流程的循环：感知、决策、行动、反馈，而 workflow 只是一个固定的调用路径的模式，一趄路径都是显式的， agent 是自动产生循环，而人也可以在任意环节介入以改变循环。但模式上两者其实是类似的
- 基本的控制流程就5种：提示链、路由、并行、编排、评估-优化模式，可以视具体情况不同组合
- harness 设计比模型重要，包含验收基线、执行边界、反馈信号和回退手段，这是系统能否稳定运行的关键
- openai 的做法：
- 所有知识都在代码库本身，但 agent.md 只保留索引
- 多使用 lint / ci checker 的机制代替文档约束
- agent要完成端到端的工作，有问题改善工作流而不是让人介入
- 最小化合并阻力，遇到失败主动重跑，而不是让人来修复
- 不断提高可见性，所有的日志、指标、追踪都向量化，提供查询接口，让 agent 自主推理
- harness 最适合可以被标准化验证，有明确索引的创造。而比如发明新架构，或依赖人类决策的事情，不是他的强项
- 上下文管理是能否让 agent 稳定完成工作的最重要实践，合理分层能让他保持清醒不丢任务，常见的分发：常驻层、按需加载层（skill/spec/rules）、运行时注入、记忆层、系统层。常见的压缩方式：滑窗、摘要、工具结果替换。
- 固定的内容会触发 kv cache ，所以稳定的内容放在 prompt 前面，动态的内容放 prompt 后面，可以优化调用速度
- skills 是一种能力索引的技术，但索引也是每次都全量加载的，所以索引本身也要够短够明确
- 压缩方法也可以写在 agents.md 里，避免 agent 把我们认为关键的东西压缩掉了，特别是 uuid 或 commit id 之类的索引信息，不然压缩就白压缩了
- 用文件输出而不是直接输出到对话上下文中也能明显优化上下文，比如工具调用输出到 json ，再用 grep 等工具读结果
- 好的工具设计对 agent 也很重要，其发展历史也从普通的 api 调用封装（tool call），到 tool search 这类的先索引再调用的模式。用 zod schema 这类实践，能把定义和实现放一起，有效优化调用。
- 记忆系统是 agent 能否跨 session 持续工作的重要工具，通过使用 token usage 的评估，对旧记忆有计划的遗忘，能有效提高效率。
- 对于长 session 任务，如架构迁移，就应该分多角色，最简单的是 Initializer Agent 和 Coding Agent 角色，然后把状态显式的写出来，同一时间只有一个 in progress ，让 agent 有上下文的锚点
- 多 agent 组织常用统筹者模式，就是一个 agent 分配任务，其他 agent 分工，最后审查产出。子 agent 可以自由探索，只返回结果给主 agent ，让主 agent 在任务上保持专注。
- 多 agent 下，幻觉会被放大，所以必须要有协议和门禁来控制。子 agent 要避免有孙 agent ，并且限制他的能力，避免称为另一个主 agent 而迷失
- agent效果的评价目前还是靠人来打标，使用 pass@k 来做能力判断，passk 来做回归测试
- 评价体系的搭建可以从20-50个真实的失败案例开始。测试用例要正面案例少，反面案例多。然后再逐渐的增加人工打标和模型评分器。另外很多 agent 的评分下降并不是模型导致的，而是评测系统本身的问题
- 可观测性是 agent 搭建的重要工作。对其评估也是首先人工标注，然后 llm 自动评估。对在线用户的不满反馈，需要 100% 进队列，高成本对话高概率进对列。其他可以随机采样。
- 最后介绍了 openclaw 的一些实践，包括 cron ，系统分层，会话恢复。
- 最后总结一些常见的问题：系统提示不能当知识库、工具数量要控制、验证必须闭环、多 agent 之间必须隔离有边界、需要有评测、不要过早引入多 agent 、约束期望必须依靠机制。
我的观点
- 价值：一篇总览式的 agent 搭建文章，可以快速入门。里面的经验大多是我也已经了解的，但如此全面的总结出来，很适合当成一篇宣传文，帮助其他人快速入门。
我对 Spec Driven Development 的看法 - Zhiqiang's backyard
要点
- spec 驱动开发并不是银弹，因为文档和实现之间的差距是巨大的， cc 之类的用 plan 模式也无法解决这个问题，能写出好的 prd/spec/plan 不等于能写出好代码，不被 spec 覆盖到的地方就是 ai 实现很糟糕的地方
- 软件工程师很清楚，可维护性是软件生命周期的最重要的价值，而不是迭代速度。但产品和运营不知道，他们只认为 ai coder 输出代码很快，以至于很多工程师现在也无法坚持自己的观点，随波逐流
我的观点
- 价值：一家之言，但确实这个问题是存在的。只有 prd 存在的情况下，代码实现就是不可靠，我自己的经验也是这样的。所以我们需要增加更多顶层设计，更多额外流程和门禁来封堵。软件工程师的未来一定是 agent 控制师。
宝玉：AI 发展太快跟不上？一张四象限图帮你做减法
要点
- 4象限法，确定是否要在这个领域投入 ai 学习的精力
- 离生产力远､保鲜度也短的： ai 套壳、模型排名、各种产业新闻和八卦，应当当即放弃
- 离生产力远、保鲜度长的：比如 rag 原理，CoT，多模态能力等，了解一下就好，不需要特别深入
- 靠近生产力近、保鲜度短的：比如 ai 生图，ai做 ppt ，可以花点时间，能用就行，不用深纠，多用用，好用就用，不好用就放弃
- 靠近生产力，保鲜度也长的，比如 cc 的各类技巧， skills ，上下文工程，应该花大量精力，彻底搞懂，并加入到日常工作中
- 这个地图也是会飘移的，需要定期回顾，关键信号是：谁在用（越普通人用说明这个领域越靠近生产力，越保鲜），背后投入（有多少公司花很大精力和财力在这个事情上），是否收敛（是不是有最佳实践跑出来了）
我的观点
- 价值：很好的面对 ai 焦虑的文章，也是可以帮助大家判断一个 ai 方向是否有价值的方法论
yan5xu：最近一些 Agent 认知：OS 与 Agent-native 应用
要点
- 垂类应用不应该做 agent ，因为这是基础能力问题，类似 os ，而也不能做 skills ，因为无法解决被 copy 的问题
- 垂类应用应该抓住3个层面：
- 领域上下文，比如法律服务记住案件进度和判例引用，投资服务记住持仓逻辑和调仓理由
- 基础设施成本，比如领域小模型的投入，法律案卷，和实时数据管线
- 规模成本，由客户量带来的成本摊薄等
- 垂类应用能成功的根本性的突破点：
- 能力解锁，以前因为 agent 的上下文或带宽限制做不到的事情，现在做到了
- 认知卸载，以前很费力的事情，把 agent 本身做的事情放到外部，减少噪音，一次性就能把任务做准
我的观点
- 价值：一套有价值的实践思考分享，对 agent 应用开发者的一个提醒，原文写的很发散，但想法上就是垂类 agent 开发者首先要解决垂类本身的问题，再利用 agent 实现规模化，可能才是重点。
数字游民Jarod：什么是品味（taste）？- 以及如何获得品味
要点
- ai 天然是产出最平庸而普遍的东西，此时品味就变的很重要
- 品味不是个人偏好，因为你在宣称某个东西是好的时，也在宣称别人也应该认为他是好的；品味不是阶级属性，他是一种从平常中找到有价值的点的能力；品味不是要会技术，而是一种回答”什么值得做“的能力
- 如何获得品味：敏锐感知力、精细的情感、通过实践提升、通过比较完善、清除所有偏见，其中最难的是清除偏见，因为这意味着你需要去接触你不喜欢的东西，而放弃自己喜欢的东西。
我的观点
- 价值：ai时代最重要的是洞察力，因为怎么做已经不重要了。这篇文章是一个引子，但始终有一点，实践和反思始终是培养品味最重要的方法，多做多想没错的。