Stephan

后端技术专家 | Learn to build with AI | 热爱开源精神 | 分享最前沿AI资讯，以及我的深度思考和实践

[Stephan @Stephan_Talk]

@dotey 其实写作的好坏也是可以一定程度上验证的，不过评判标准很复杂，大概率还得依靠人类专家先定出一套金标集，再在此基础上建设验证工具

[Stephan @Stephan_Talk]

@dotey /retro 这类复盘 skill，我的体验是需要有明确的改进目标，否则就是散弹式的建议意义不大。所以我觉得 pstack 的 /recall skill 更贴切一些，它的重点是帮我召回，并根据我的明确改进目标来匹配召回中的内容

[Stephan @Stephan_Talk]

之前我花在 grill-me 的时间非常多，我不能说它没有价值，而是它容易过度细节而漏掉真正需要关注的地方

pstack 不同，它倡导用可信的验证代替对抗性审查

我发现验证不仅可以在实现完成之后做，更好的方式是在设计阶段就跑出多套快速原型方案，让智能体对几套方案进行验证、评审并留下证据

这比对抗性审查有效的多，我直接看到不同方案的对比证据，而不是靠猜测和过度设计

这些原型方案是实际的代码，而不是设计文档。这也大大提高了设计方案的可信度

更重要的是，这种多套评审机制，不用人类在 grill 过程中“权衡和猜测”哪套方案更优。因为可以直观的看到不同方案的结果，实际决策过程甚至很多时候不用人类来做

[kaito @cu30rry_]

敵対的レビューよりも検証と、その質を上げることに時間とトークンを使ったほうが絶対良い！

検証を徹底して、検証の質を上げるほうが、敵対的レビューをするより遥かに効果的だし、信頼背も高く、人間が介入する場面が減る

敵対的レビューは、ハーネスを設計しないとハルシネーションが大量に出るし、その仕組を作ってもトークンの消費が激しく、効率も悪い

指摘の根拠・その根拠を再現する方法を報告させ、それが本当に再現するかをエージェントが判断し、人間も最終的な結果を確認する必要があり、成果物の信頼性が形式検証に遥かに劣る

[Stephan @Stephan_Talk]

@cu30rry_ 非常感谢！🥰

[Stephan @Stephan_Talk]

@kev1nyoung2023 @poteto 可以的，我使用以下开源项目来适配 pi 环境：

https://t.co/S4qbbEEmjz

[Stephan @Stephan_Talk]

https://t.co/IeNJdgnhMJ

[Stephan @Stephan_Talk]

@kev1nyoung2023 我不是 grok bot 的开发人员，只是对 pstack 感兴趣。我喜欢费曼学习法，在分享的同时学习知识，所以翻译了 @poteto 的文章

[Stephan @Stephan_Talk]

@xiaomovps 在输入框中能否支持任意位置的 skill 输入补全？不知道是不是我不会用，每次都要在输入框最前面才能补全 skill

[Stephan @Stephan_Talk]

@cu30rry_ 非常赞同

[Stephan @Stephan_Talk]

之前分享过的一篇 Anthropic 的讲爬山优化的文章，可以作为一个入门参考：

https://t.co/4R4LHWcOYN

[Stephan @Stephan_Talk]

https://t.co/0LQXfrtkBd

[Stephan @Stephan_Talk]

非常赞同这句话：不管你向一个问题投入多少智能体和智能，没有适当的评估，你都走不了太远

在我看来，一个出色的智能体系统应该具备两样基础设施：自我验证和评估

验证的目的是让智能体的功能迭代不会出现设计偏差，它解决“构建新功能”的信任问题

而评估解决的是对已有系统的优化能否持续有效的问题

在你拥有一套可靠的评估系统之前，不要对你的目标系统做过度优化

最近打算开源一个我针对通用翻译场景做的评估工具，届时我再详细分享下我是如何做评估的，期待和大家一起交流

[elvis @omarsar0]

Learn to build evals, folks!

You're not really doing recursive self-improvement (RSI) if you are not doing evals. And don't tell me your agents are generating the evals for you. They are pretty bad at it.

I have found it really interesting and useful to give agents a concrete way to measure results and stay on track with a long-term goal. It's easier to hill climb when things are clearly measured and well defined. Probably one of the most important skills anyone in the space can have today.

It doesn't matter how many agents and intelligence you throw at a problem; you are not going too far without proper evals.

[Stephan @Stephan_Talk]

@wtfARUUU 哈哈谢谢，还是 lauren 厉害，我只是总结了一下

[Stephan @Stephan_Talk]

《pstack 完全指南 pt.2》重点总结

这篇解决两个问题：
1. 如何与智能体对齐需求
2. 如何进行有效的规划和设计

如何与智能体对齐需求

lauren 会组合使用以下四个技能：

1. /how: 系统现在怎样运行？
2. /why: 为什么这样设计，有什么历史约束？
3. /recall: 过去的对话提供了什么背景上下文？
4. /teach: 能否讲清机制与原因，让人检查理解？

举例：
> /recall 我过去 7 天修复虚拟化 bug 和性能问题的工作。使用 /how 和 /why 了解我们当前的虚拟化实现是如何工作的

* 注意，/recall 能自动搜索你的 harness 的会话历史记录，但这并不是唯一方式。它的目的是为智能体扩充你的环境上下文，以便智能体能有更加全面的视角。所以我认为在这个阶段应该尽可能多的给智能体主动提供环境上下文，比如日志、数据库、外部依赖、外部文档等

这样沟通的好处不仅限于让人类更能全面的理解当前现状和问题，更重要的是推动智能体掌握更全面的上下文，避免它们基于少量的信息匆忙得出片面的结论

* 另外推荐一个我觉得很好的 skill: https://t.co/RsvuZtFbJQ ，当智能体长篇大论或不说人话时，我就会用这个 skill 帮我生成一个网页来理解

如何进行有效的规划和设计

第一，lauren 推荐一种 “逆向工作法” 叫 README 驱动开发 。具体来讲她会用 /technical-writing 技能，在规划阶段写出不同层次的用户教程，打磨好后的教程将成为智能体的行动目标

把写用户文档作为打磨设计文档的手段，好处是可以站在 high-level 的视角逐层打磨设计文档，而不是事无巨细的 grill-me

第二，她建议 “用代码来做规划”，她会使用 /poteto-mode 原型设计工作流 来进行快速原型开发，使用 /architect 技能扇出（Fan-out）多个并行智能体产出不同候选设计方案，最后综合成一份最优设计方案并进入实现

多个并行智能体扇出的方式，有点像赛马机制。核心思想是利用不同家族的模型进行并行研究，以避免单一模型的局限性。然后从所有返回的内容中综合整合出最优方案（不是只选一个模型的结果）。这种机制在 pstack 的整体设计中会有多处体现

这里需要注意，并行赛马比较的并不是最终实现，而是草图、类型定义、接口定义组成的一套接口规范层面的设计草案

lauren 特别提到，她“从不费神去对抽象计划做对抗性评审”的原因就来自于此。如果用类似 grill-me 这类 skill，难免会陷入纸上谈兵的境地，既费人又容易过度设计。而让代码自己去竞争评审能更落地且节约人脑细胞

补充说明一点：/architect 在 D 阶段人类确认后，会自动进入实际代码的实现阶段。这里如果你是比较大的任务，可以在人类确认后掐断（pstack 有提供其他的长周期任务工作流），举例如下：

> /skill:poteto-mode 为 <功能> 制订实现计划。先用 architect with checkpoint 完成设计并暂停。本轮不要进入 Phase D，也不要实现功能逻辑。将设计方案转化为一份计划

---

以上是我在看了这篇文章以及相应 skill 源码后的一份总结，有趣的是我在总结过程中就已经会应用上以上提到的技能了。包括下面这张图的文稿也来自于 /teach 和 /technical-writing。所以大家如果有不懂的地方，非常推荐直接跟 pstack 对话，另外更推荐直接看它的 skill 实现，很多宝贵的设计思想

/architect skill 流程图

[Stephan @Stephan_Talk]

https://t.co/S2JIjdCEKn

[Stephan @Stephan_Talk]

@CyanCloud77 今天我发的推文还在推荐你的 skill 呢，很好用！

[Stephan @Stephan_Talk]

@wtfARUUU 哈哈多谢多谢！😊

[Stephan @Stephan_Talk]

https://t.co/S2JIjdCEKn

[Stephan @Stephan_Talk]

@BeWater0101 感谢推荐，他写的 skill 值得好好学习一下

[Stephan @Stephan_Talk]

《pstack完全指南 pt.1》总结

核心的验证能力
/create-verification-skill 本质上提供三种能力：

1. 验证技能入口

驱动你的应用执行真实的验证流程，例如通过浏览器工具执行真实的应用截图、点击、发送消息等动作。通过这些动作做自动化端到端验证，定义验证标准并拿到证据

2. CLI 工具

为了能高效验证，/create-verification-skill 会配套的生成一套针对你应用的 CLI 工具，以便验证技能能够通过这些工具高效且低成本的执行验证

3. 功能地图

/create-verification-skill 还会生成一套针对你当前应用的功能地图文档，这套文档成为验证执行时的“锚点”，比如全面回归验证会遍历功能地图的所有功能点进行验证

当你调用 /create-verification-skill 时，它会将以上三种能力结合在一起，生成一个 skill 包放在你的当前项目目录下，以便你随时调用验证

大家如果对以上的概念感觉比较模糊的话，lauren 还特别写了一个 example 项目，可以让你看到验证技能跑完得到的这套 skill 包具体长什么样子：
https://t.co/Ct0UtszONS

配套的 /maintain-verification-skill 技能用来更新验证技能生成的 skill 包。最佳实践是起一个定时任务定时跑这个 skill，以保障你的验证技能包是随项目迭代不断更新的状态

对于文中提到的 “用云端智能体代替 worktree” 的方法，我倒是觉得不一定需要。云端智能体需要更多成本以及更加完整的环境上下文，对于大多数小型项目来说一套本地开发测试环境 + 一套预发布验证环境我觉得就足够了

---

另外，如果你当前使用的 harness 不是 Cursor，想使用 pstack 的话，以下这个开源项目就是为你准备的（我横向比较了多个项目，这个是我觉得支持面最广且社区更新最频繁的一个）：

https://t.co/Wjm4uAxisE

它支持 Claude Code、Codex、Copilot、Pi、OpenCode 等 harness 使用 pstack，且会紧密同步 pstack 官方的发布。利用它你可以在无需 Grok 订阅的情况下使用 pstack

[Stephan @Stephan_Talk]

https://t.co/IeNJdgnhMJ

[Stephan @Stephan_Talk]

@wtfARUUU 好问题！其实 pstack 考虑的会更深入一些，关于拷问这个话题，在第2部分会有详细讲解（今天我会发出来），等你读完就会明白

[Stephan @Stephan_Talk]

分享下我在多 Agent 管理时的一点经验：

1. 不要把任务切分的太细，重点放在设计和验收

正如宝玉老师所说，管多 Agent 正如管人一样。新的技术管理者最容易陷入的误区就是事无巨细的管，导致自己最容易成为瓶颈

管 Agent 也是，如果每个 Agent 的执行粒度是几分钟的话，很快人的脑袋就晕了，上下文切不过来，也容易管出问题

我目前体会是每个任务控制在小时粒度（长的话有几小时的）是最舒服的，这就需要设计阶段多花些时间和 Agent 调研和讨论，形成文档化的共识后让它去慢慢跑。与此同时我再切到下一个 Agent 讨论和布置任务

2. 验收要落在实处，“多少测试用例绿了” 不能说明任何问题

Agent 在跑长程任务后很容易跑出几十上百个单元测试，这些不是质量证据，甚至不能说明 spec 的遵从度。只有从设计角度出发，写一套符合需求的端到端验证，拿到验证证据才算数

这方面特别推荐使用 pstack 的以下两个元技能（用来创建skill的skill）：
/create-verification-skill
/create-formal-verification-skill

第一个能帮你创建一个 e2e 测试的基础设施、以及当前项目的功能地图，根据功能地图进行真实的e2e测试：

https://t.co/oAV599JOyu

第二个是对第一个测不到的地方的补充，比如无法枚举的测试、并发竞态条件等，用形式化验证来做数学证明，确保复杂状态的正确性

相对应的 lauren 还提供了两个维护更新这两个skill的元skill，简单说就是项目功能在不断迭代过程中，验证类的skill也要随项目不断更新才行

3. 与多 Agent 的沟通方式：不要打乱自己的节奏

刚开始管理多 Agent 的时候，我开很多窗口，一有 Agent 完成任务了我就切过去看，很快证明这样马上就会乱成一坨

多 Agent 管理必然是异步沟通的方式，这有点像是 CPU 的时间片切换，不应该一有消息就马上切，而是 Agent 异步通知 → 我看到通知了 → 等我把手头的一个检查点工作做完 → 再切过去接收

Agent 永远是在挂起等我反馈，而我只有做完当前“线程”的阶段性事务才会切我的注意力过去

目前我的窗口极限大概就3-4个，这和当前 AI 的长程能力也息息相关（如果未来Agent可以按天高质量交付了，这个窗口数就能扩大）

4. 反模式：单任务不要过大

按照当前的前沿模型能力，我认为单任务最长控制在小时级别是合适的，到天级别很容易跑歪

之前我跑了一个几天的长程任务，跑完发现一堆问题，最后还是不得不全部回滚了

这还是上面说到的原因：当前最前沿模型的能力，我的感觉还到不了天级别

上下文窗口、幻觉、自动压缩、指令遵从性等等，会让 Agent 在长程任务上的问题会逐渐放大到不可控

---

以上就是我在管理多 Agent 上的一点经验，欢迎讨论下：你现在能控制几个 Agent ？每个的平均时长是多少？如何把控质量？

[宝玉 @dotey]

多 loop 或者说多个 Agent 自己执行任务自己验证，这种方式会成为趋势的，原推说的这些问题都存在，但都不是障碍。

这很像一个人从一个 IC（独立贡献者）晋升为 Manager，必经之路就是要学会多线程工作，把任务拆分，交给几个不同的员工去完成，然后并不是活交出去就可以当甩手掌柜不用管了，在这过程中还要不断对齐方向、提供支持、验收、合并，出问题了还要背锅。

之所以说会成为趋势，是因为人的注意力是稀缺的，而 Agent 执行任务是异步的要消耗时间的。

我日常交给 Agent 的任务平均半小时左右，甚至更久，这意味着一个任务给 Agent 后我要等一段时间才能看到结果，如果这期间我一直等着，那是低效的。

所以要充分利用人的效率，就要多开任务，让 Agent 同时做几个任务，这样我可以一直要去分派任务，去验证结果。

就算你要摸鱼，你的老板也不会让你闲着的，最终必然是每个人都被迫从 IC 转型 Manager，只是管的是一堆 Agent，每个人都要多 Loop。

如果你现在还不需要这么做，那么好好珍惜、多多摸鱼，这样的好时光不会持续太久。

之所以说原推说的问题都不是问题。

1. Agent 已经具备纠错能力，只要有合适的工具就能做很多验证的活，coding 自不用说，就连视频剪辑这种事，Agent 都能截取连续帧图片放在一起，借助多模态能力去分析。

2. Agent 也能自己检验和修正错误，只要提供验收的标准和检验的工具，Agent 就能不知疲倦的自我修正。

---

至于和使用者预期不一致，这是无法避免，但不是问题，所以要人工介入去调整。

而且你管理 Agent 方法也很重要，就像好的 Manager，不会等到项目 Dead Line 到了才去看员工任务进展怎么样了，一定是一开始就要通过文档、原型、设计去反复对齐避免理解出错，中间要设置小的里程碑防止走偏。

管理 Agent 也是类似，前期让 Agent 做 Plan、写文档就是为了保证 Agent 理解了意图，后面的验收也是避免结果不是想要的。

让 Agent 干活和人干活有个很大的不同，人做事太慢，时间成本其实很高，同样一个功能，以前人做至少周为单位，现在 Agent 是以小时为单位甚至更小，这意味着犯错的成本同样低。

就算 Agent 做错了有什么关系，让它重做并不是什么大的问题，更何况大部分时候不需要推翻重做，只要小的调整就可以了。

使用者直接、频繁的介入，要耗费大量的注意力会是常态，这是 IC 变成 Manager 的代价，我们再难回去当年 IC 单线程做事的快乐了。

[Stephan @Stephan_Talk]

@wtfARUUU 谢谢关注🙏一天内更新