Olivier Wulveryck

RSS: https://blog.owulveryck.info/index.xml
Olivier Wulveryck 的技术博客，关于 Go、AI 与软件架构。

宣言不是指南针：AIDD 四大支柱与执行循环

<p>宣言是一种你亲手签署的文件；而指导原则则是一种你付诸实践的准则。本文所要阐述的整段论点，正是建立在这两者之间的清晰区分之上。</p><p>引言</p><p>当我第一次看到（AIDD）时， 我曾觉得这是一个绝妙的构想：由开发者们基于“X优于Y”的敏捷宣言传统，以四条价值观和十二项承诺为依托， 书写而成。初读这些价值观时，我很容易就认同它们，并且愿意为之签字。</p><p>然而，随着我逐渐将这份宣言视为指导原则来践行，我的阅读视角也随之发生了转变。 在细节层面，其中一些核心理念却让我感到担忧：它们将人工智能嫁接到现有的生命周期中， 而非重新审视以代理为核心的生命体循环。 我理解当初提出这些理念时的初衷——在“氛围编码”时代，这种谨慎的做法确实有其合理性。 但如今，代理驱动的开发早已超越了“氛围编码”的范畴，模型也已实现了长足的进化。 若将这些政策应用于代理式工程领域，它们或许无法真正守护最终产品的价值——这一点我也深表赞同。 相反，这些政策很可能只会增加不必要的惯性，从而阻碍这一循环本应实现的高效运转与卓越成果。</p><p>我们不应与显而易见的事物对抗。如今，是代理编写代码，而非人类。 真正值得深入探讨的问题在于：团队应当如何保留知识，而非如何验证人工智能已经比我们做得更好的那些方面。</p><p>我在六月和七月发表的文章，正是构建起这样一套代理式交付引擎：它就是中所描述的循环， 而在中得到了进一步的放大与深化。…</p>
评论点赞收藏75 天前

同样的任务，两种结局：有无规划网关的支付集成对比

通过同一支付集成任务的两次运行对比，展示将治理规则从“文本指令”变为“可执行数据”的效果。无网关时，AI 违规在几天后的代码审查中被发现，导致人工返工；引入规划网关后，规则在规划、锁定和执行阶段被实时拦截和验证，修正仅需一次迭代。 文章提供了完整的代码片段、Rego 策略示例及 curl 复现教程，适合关注 AI Agent 工程落地与治理机制的技术人员。
评论点赞收藏83 天前

受控的技能注册表：企业级Agent能力的策略即代码

提出企业级Agent技能治理方案，将技能分为不同安全等级，并通过策略代码（Rego）在发布、安装和运行时三个环节进行验证。解决了传统包管理器无法语义理解技能风险的问题，确保技能符合架构决策。 适合关注Agent规模化落地和安全治理的技术人员。
评论点赞收藏84 天前

放大的智能体循环：护栏作为加速器

<p>引言</p><p>本文结束了自三篇博文以来所展开的系列探讨。 在《看见、行动、修正》一文中，我介绍了将代码代理从“小工具”转变为生产级工具的三大关键杠杆， 并提出了一套网格化框架，用以区分那些能够长期稳定运行的平台投资，以及那些仅能暂时应付的“拐杖式”投入。 在《谁来做什么？——面向代理型平台的团队架构》一文中，我将代理型组织映射到了这一平台架构之上。 而在《将规则固化下来》一文中，赋能团队则将自身的防护机制内嵌于平台之中， 最终悄然消融于平台的运作体系中。</p><p>这一路径的逻辑十分清晰：要从个人化的“氛围式编码”（即开发者与大语言模型“互动”）迈向工业化、 大规模的软件工程，平台——以所定义的“平台工程”视角来看，它是一种内部产品， 旨在减轻流式协作团队的认知负担——必须成为代理型劳动力的“指挥家”。</p><p>而本文所要解决的问题正是这一点：如今，所有的控制权都集中在交互的起点，而安全网却往往只在最后时刻才发挥作用：</p><p>左侧一列代表了当今工具体系的运作方式：初始阶段充满繁重的上下文信息，随后便陷入一片空白， 直到持续集成（CI）的检查门发出“否”的指令。 而蓝色的三条通道，则是本文所设计的三大核心模块：治理、架构上下文，以及在代理型循环的每个环节中由平台所服务的安全保障。</p><p>目前已有多种工具覆盖了这一领域的部分功能。通过在输入、对话、执行和输出等环节之间进行强制性约束， 实现了对流程的全面…</p>
评论点赞收藏85 天前

编码规则：构建智能体软件交付生命周期背后的平台

<p>引言</p><p>本文是我们对.在组织规模上——跨多个产品和团队——构建可靠的软件， 需要我们根本性的运营方式转变。</p><p>在现代的人工智能驱动软件交付生命周期（SDLC）中，流程对齐的团队应完全专注于解决方案， 将实际实施委托给人工智能系统。这个智能循环是现代软件的引擎，直接由一个强大的内部平台驱动， 提供模型和推理引擎。</p><p>但我们怎么启动这台发动机而不让它脱轨呢？</p><p>仅靠技术还不够;我们需要合适的人类协作。 为了构建功能性、可靠且值得信赖的应用，产品专家首先必须与技术专家合作。 这使得团队能够参与构建人工智能、建立关键防护措施并制定企业标准。</p><p>归根结底，这篇文章讲述了一个循环的故事。 赋能团队收集这些技术护栏，并将其直接内置到平台中，作为自动化治理规则。 一旦平台吸收了这些知识，支持团队可能消失——留下一个能够开箱即用、生成标准、 可信应用的代理系统。只有当出现全新的技术挑战时，它们才会重新出现。</p><p>让我们来探讨如何构建和掌握这些循环，首先快速回顾一下开发引擎的工作原理：代理循环。</p><p>tap 以扩展</p><p>&lt;条目类别=“st-叙事”&gt;</p><p>agentic loop</p><p>这部分并非任何形式的创新。它提醒我们智能循环是如何运作的。 然而，理解这一基础非常重要，因为它是软件交付的核心节点。在本文的剩余部分，我将大量依赖这些原则。</p><p>代理循环是现代由人工智能驱动的软件交付方式。 你首先表达你想发展的某个项目的意图。</p><p>LLM理解意图，然后规划一…</p>
评论点赞收藏88 天前

当AI代理拒绝在未获付费时工作

<p>暴露问题</p><p>为每个开发人员提供一个强大的本地人工智能代理感觉就像是终极生产力黑客。 但对于大规模运营的组织来说，这是一个 治理和成本陷阱 等待春天。</p><p>目前，软件开发生命周期 (SDLC) 中的人工智能革命几乎完全发生在开发人员的笔记本电脑上。 我们正在构建孤立的整体代理循环。 我一直主张转向代理平台，因为我相信这种本地优先的方法只是暂时的。</p><p>但在解释该模型为何失效之前，我们先来定义一下“大规模”运行 SDLC 在此背景下意味着什么：将人工智能驱动的开发带入 N 个团队致力于 M 个产品，其中 N 和 M 都大于 10。<br><br>我们谈论的不仅仅是单个团队的内部动态，而是真正的多产品组织。</p><p>确保组织层面的信任</p><p>让我们考虑一个基本事实：法学硕士是概率性的，这意味着人工智能指令仅在一定比例的时间内得到遵循。 想象一下，您创建了一项技能来执行关键业务规则，我们将其称为“企业架构决策”。 ”</p><p>由于人工智能的本质，这项技能总是有可能被部分忽视或应用不当。</p><p>如果失败率甚至是 10%，并且您将其扩展至 N &gt; 10 个运行数千次迭代的团队，那么从数学上讲，您可以保证某些团队将发布绕过您的全局业务规则的代码。 这导致大量 建筑漂移.</p><p>当然，我们可以使用钩子和程序构建确定性护栏来强制验证。 但如果这些是在开发人员的笔记本电脑上本地执行的，我们就会失败 集中可观测性.</p><p>CTO 或首席工程师最终对品牌的软件负责。 他们不能仅仅依靠“信…</p>
评论点赞收藏94 天前

谁做什么？代理平台的团队拓扑结构

<p>代理型平台定义了需要提供哪些服务。团队拓扑结构则明确了由谁来提供这些服务，以及各团队如何相互协作以实现这一目标。</p><p>这是第二版，采用更贴近人类语言的表述。第一版大致是人工智能完成的翻译版本。本版由人工编辑而成，希望能让读者读起来更加顺畅、易于理解。</p><p>在系列文章的第一篇中，我们提出了一个核心问题：“究竟需要哪些系统性能力（如上下文、<br>监管机制、工具体系）才能在规模化场景下打造可靠的应用？<br>”答案是：代理型平台，而其核心则是“代理型工厂”——一个让代理们负责规划、<br>编码、测试并最终交付应用的机制。</p><p>然而，平台本身并不会自动构建，更重要的是，它并非以与构建时完全相同的方式被使用。一个根本性的问题依然存在：“到底是谁在做什么？”</p><p>真正的难题：认知负荷的压缩</p><p>在追问“谁来做什么”之前，我们需要先弄清楚，为什么这一次的问题表述有所不同。</p><p>开发一款软件应用，本质上是在时间维度上协调各方角色：设计师、架构师、测试人员和运维工程师。<br>整体复杂度确实很高，但这种复杂性是分散在多人之间，并且随着时间推移不断延展。<br>每个角色都会依次提出自己的问题。</p><p>AI代理改变了这一局面。它们不再局限于回答孤立的问题，而是能够持续生成输出。<br>由于代理能够即时执行任务，传统的顺序式问题解决流程被彻底打破。<br>所有这些问题如今都必须由指挥决策的人类提前预判，并在短短几秒的提示窗口内予以回应。<br>如果提示框架设计得不够周密，代理不仅不会放慢速度，反而会产出快速却…</p>
评论点赞收藏99 天前

规模化下的 Vibe Coding？工程体系的反击

<p>生成式人工智能彻底改变了代码的生产方式。 短短几个月间，我们从仅能实现自动补全的工具，发展到能够编写、测试并部署整套应用程序的智能代理。 如今，市场中充斥着各种各样的方法，用于为这些智能代理构建框架，并使其产出高质量的代码。</p><p>然而，这种海量的工具选择也引发了一个鲜少被企业关注的问题：当您并非只打造一款应用，而是打造五十款应用时，会发生什么？</p><p>答案在于一个每个人都容易忽视的差异：一款软件即使“设计精良”，也可能并不符合“预期标准”。 结构化人工智能方法虽然能够达到“一流”的水平——也就是业界普遍认可的通用标准。 但一家企业的“一流”却属于“自身”：它基于特定情境，经过共识达成，且始终处于不断演进之中。 而这一点，正是人工智能所无法完全掌握的——在每一个项目中，它往往只是粗略地进行重新构想， 甚至失之于粗疏。</p><p>“行业前沿” ≠ “你的行业前沿”</p><p>让我们先澄清一个根本性的误解：不存在绝对的质量标准。</p><p>正如克里斯托夫·蒂博在《如何终结技术债务》一文中所提醒我们的那样：“‘质量’这一单一而普世的概念并不存在。 在雅典广场餐厅，你只需花费约380欧元就能享用一顿极佳的美食； 而在麦当劳，午餐价格不到8欧元，同样设有质量部门。 这两种标准截然不同——而且在各自的语境中都完全合理。 只要将它们的评判标准互换，就会出现两种荒谬的结果，而没有人会愿意为此买单。</p><p>所谓“行业前沿”，是指某一团队在明确或隐含的共识基础…</p>
评论点赞收藏103 天前

关于工程级代码代理，我希望早点知道的几件事

文章提出编码代理的“SEE-ACT-CORRECT”三杠杆模型，强调上下文窗口是稀缺资源，需按需打包。 指出验证环节常被忽视，导致生产力悖论。 建议优先投资能随模型进化增值的“放大器”工具，而非补偿性手段。
评论点赞收藏116 天前

用 Go 构建智能体系统自动生成 Google 幻灯片：我的实战心得

一位顾问分享了用 Go 语言构建多智能体系统自动化生成 Google Slides 的实践。系统通过分离大纲、选择、写作和审查角色，解决了模板填充的机械问题。 作者强调代码并非核心壁垒，精心设计的 300 页咨询演示模板库才是关键护城河。文章详细记录了从单体原型到模块化架构的工程决策及 ADR 文档。
评论点赞收藏120 天前

智能体网格：规模化认知自动化架构

作者提出“智能体网格”架构，主张将AI智能体视为独立软件产品进行工程化管理，而非简单的提示词组装。文章借鉴数据网格理念，强调智能体需归属业务领域，并通过标准化契约和自动化治理实现大规模协作。 该方案旨在解决当前企业级AI应用中智能体缺乏工程严谨性、所有权不清及难以规模化复用的问题，提倡建立数字平台基础，逐步从原型过渡到生产级的智能体生态系统。
评论点赞收藏121 天前

AI学习循环中的人类局限：为何RLHF可能阻碍智能突破

文章对比了 AlphaZero 的自我博弈学习与当前基于人类反馈强化学习（RLHF）的大语言模型。指出 RLHF 虽然让 AI 更听话，但也限制了其超越人类认知的能力，因为人类评估者往往缺乏领域专业知识。 作者主张重新引入基于现实结果的“接地”反馈，让 AI 像 AlphaZero 一样在模拟或物理环境中通过试错来发现人类未曾设想的新策略，而非仅仅优化取悦人类。
评论点赞收藏500 天前

MCP的3个U：让工具对LLM有用、可用且被使用

作者以记忆图谱工具为例，指出LLM因缺乏约束会随意创造关系词，导致数据混乱。引入本体论和MCP Prompt可提供语义引导，确保工具被正确使用。 文章强调MCP工具设计需考虑AI用户的“可用性”，通过清晰的文本描述和Prompt，解决LLM交互中的语义歧义问题。
评论点赞收藏524 天前

从零构建基于 Go、VertexAI 和 Gemini 的 MCP 智能体系统

本文是系列文章的第一部分，主要介绍 Model Context Protocol (MCP) 的基础概念。作者解释了智能体如何通过标准化协议与外部环境交互，以及 MCP 如何定义资源、工具和提示词的标准接口。 文章还探讨了 MCP 对商业范式的影响，认为其可能引发下一轮数字革命，使智能体成为连接用户与企业服务的关键枢纽。
评论点赞收藏606 天前

MCP 实战三部曲之三：为特定用例构建自定义 DuckDB 服务器

本文是 MCP 系列教程的第三部分，作者以实际场景为例，演示了如何从零开始构建一个基于 Go 语言的自定义 MCP Server。该工具封装了 DuckDB，允许 AI Agent 直接查询本地数据文件。 文章详细讲解了 JSON-RPC 协议的封装、工具注册以及通过 STDIO 进行通信的具体实现，并提供了完整的代码示例和运行结果，适合希望深入理解 MCP 协议落地的开发者。
评论点赞收藏611 天前

如何利用数据激活价值飞轮效应

作者结合David Anderson的价值飞轮理论，提出激活数据驱动业务的四阶段模型。从明确目标、评估技术现状、快速迭代到长期治理，强调数据工厂在跨部门协作中的核心作用。 文章将业务战略与技术架构结合，为CDO和CTO提供了一套组织数据成熟度的参考框架。
评论点赞收藏633 天前

适合博客篇幅的微数据网格实践

作者以个人博客为例，演示如何在小型生态系统中应用数据契约（Data Contracts）。通过将书籍内容切片并转化为结构化数据，再结合生成式AI进行语义检索， 展示了跨领域数据协作的可行性。 文章详细介绍了使用Bitol标准和CUE语言定义数据契约的过程，并通过代码示例验证了从数据生产端到消费端的全流程。这种实践为理解数据网格和数据治理提供了具体的工程视角。
评论点赞收藏828 天前

构建数据产品时，我们的工程实践在哪里？

作者从零开始用Go语言构建了一个简单的RAG应用，以探索数据产品的工程实践。 文章记录了从数据清洗、Embedding生成到向量相似度计算的全过程，并总结了关于数据授权、分段策略及提示词工程的五点经验教训。
评论点赞收藏879 天前

化繁为简：从 WebSockets 到 HTTP 流的演进之路

作者开发 reMarkable 平板手势控制工具时，放弃 WebSockets 改用 HTTP 流传输事件。 原因是 WebSocket 调试困难且依赖第三方库，而 HTTP 流更简单、符合 Unix 哲学，便于直接操作字节流。
评论点赞收藏1033 天前

登录芦苇

登录后关注作者、收藏内容和参与讨论。

热门话题

人工智能12,865 人关注AI 会怎样改变日常工作？产品思考8,243 人关注怎样判断一个产品值得长期做？独立开发5,917 人关注一个人如何持续完成作品？
关于芦苇 · 联系我们 · © 2026 芦苇