Porter Zhang2026-05-27 来自北京黄佳老师，想问一下第二代分布式设计模式，除了您说的《release it》这本书还有别的吗？我在国内好像没搜到，感觉自己第二代的设计模式学的都很碎。作者回复: 1. Building Microservices 最流行的微服务入门经典。就是那个封面上有一堆小蜜蜂和蜂巢那个的书。很有这个设计和结构隐喻感。 2. Chris Richards《Microservices Patterns》微服务设计圣经 3. 云原生/Kubernetes路线《Cloud Native Patterns》 4. DDIA 分布式数据系统理论集大成者 佳哥的DAA (Designing AI Agents)就是对标这本书写的 5. Site Reliability Engineering SRE book 这是Google 工程体系圣经。 6.... 未完待续 大家继续补充
5
小学生2026-05-28 来自北京咖哥，在 软件工程 3.0 时代，如果在业务上如果已经确定了某种Agent设计模式，后续开发迭代是不是只需要对Agent微调（反思?）就好了。作者回复: 问题引起的思考比较大。我先试着回答。我感觉我们可能需要区分什么是设计模式，什么是业务架构选型。 设计模式在Agent时代应该是不能随意确定。而且，一个架构中，应该是包含许多许多设计模式的组合。
2
Cassie2026-05-27 来自广东从前端开发的视角来讲，以前在写项目逻辑时使用GoF的设计模式会偏多，单例、工厂、观察者、访问者等等，会比较有章法，但是现在aicoding中，会存在把控不了模型生成的方式，不知道我这样描述的清不清楚，看上去加了一堆的mcp，skill，tools，做了一堆限制，或者写了一个相对结构化的angents.md，不能保证每次的产出的确定性，会让开发者陷入到某种混乱的逻辑圈里，看似定义了范式，但是执行结果还是会有这样那样的问题，佳哥说的每一个模式都是在不确定性下保证系统行为可靠的工程纪律，让我觉得非常非常有学习的必要，非常喜欢看佳哥出品的栏目，点赞作者回复: 你谈的已经特别清晰。这是从生产实践一线带来的真实感知。很宝贵。 以前——“结构定义完 = 行为确定” 现在——“结构只能提高行为稳定概率” 工程目标从“绝对正确”变成“在不确定性下保持系统可靠”。 Agent Design Pattern 的本质和大原则是不确定性控制纪律。这就是设计反转，以前的设计模式本质是程序结构和设计流程掌控技术。😁
2
凛2026-05-27 来自广东认知升级很关键，这是软件工程 3.0 时代程序员认知带宽跟不上 AI 速度的尚方宝剑，里面的各种讲解，不能同意更多...期待老师持续更新内容 ：）作者回复: 感谢您，感谢大家。这份时代进化的精彩和喜悦，我们分享给读懂了这个时代的朋友 🌷🌷
共 2 条评论2
May2026-05-27 来自上海做了这么多年后端软件开发，背过十几种设计模式，学过分布式CAP，从来没有思考过为什么会有这些变迁。佳哥的第一章相当惊艳，从上帝视角把30年软件工程的经验抽象出来，总结出三代设计模式的演进，并分析了Agent时代模式变迁的根因在于决策权从开发者搬到大模型以及高不确定性，还创造性地建立了Agent坐标系双轴框架，感觉新世界门被打开，开始重新梳理这些Agent的知识点，跟着佳哥把他们串起来系统地学习坐标系和工程方法论。另外，配图也很赞，是中国传统的国画风，很有韵味很喜欢。作者回复: 嗯嗯嗯 佳哥就是想让大家出一身的鸡皮疙瘩。
2
PatrickL2026-05-28 来自上海发现了同构之美~ GoF：观察者模式->单例模式->策略模式->工厂模式 OODA环：Observe->Orient->Decide->Act
轩爷2026-05-28 来自北京5、Harness vs Prompt 优先级：如果今天给我们 1 周时间提升一个 Agent 的可靠性，我们会选 (a) 调 prompt 让模型这次别犯错 / (b) 改 harness 让模型永远没机会犯错？为什么？ 尝试回答一下，我选B。 prompt调用LLM的结果存在不确定性，虽然可以写出严格规范的prompt对LLM输出进行约束，但每次这么干，等于越来越负重前行。 harness从权限、上下文、hooks、工具、记忆等多方面对LLM运行时进行约束，让我想要的，无需过多人工干预，就能得到有边界限制的结果，属于轻装前行。