近期笔者在投入变更风险防控开放平台的额外功能开发，目的是希望设计一套更加灵活的变更风险观测策略匹配机制，能够在满足面向任意变更场景应用观测策略的同时，尽可能保证产品体验，让用户清晰地了解到自己配置的什么策略能够在什么情况的变更过程中生效。在先前的文章当中，有粗浅提到变更观测策略匹配的事情，但没有深入探究，并且笔者以前接手的项目，很多底层设计的技术债也难以偿还，要在以前实现的基础上再做重构也不是很现实了。
所以，趁着扩展新系统的机会，笔者重新思考了下变更风险观测策略匹配机制的事情，跟随这篇文章来抛砖引玉下自己的想法。
首先，还是一个根本问题，一条变更风险观测策略的粒度是怎样的？如果粒度太粗，那么从产品视角，很容易导致「所见非所得」的问题；如果粒度太细，那么用户配置起来也会相当麻烦。经评估，由单个检测能力执行的粒度代表一条策略，这样的形式相对合理，不仅方便产品层面做「所见即所得」的设计，而且实际执行过程中，也可以以原子化的形式做编排，从调度角度来讲也很容易扩展。
详细来讲，一条策略在设计上，需要关联以下几类概念：
去年年底一段时间，笔者参与了组织内部智能化平台项目研发攻坚，虽然主攻平台工程部分，但多少也了解了下目前AIGC可以应用到的一些业务场景，以及技术实践、项目管理的一些事情。在先前的文章里头，有浅要描述下AIGC+Web类项目的角色分工和配合。那今天这篇文章，就浅聊一下如果你即将深入此局，适应一个复杂的后端项目开发，有什么方法论是可以通用的。
主要是两个关键点：（1）理解产品及概念实体联系；（2）主动拆解目标各个击破。
2025年算是LLM增强产品井喷的一年，以笔者亲身经历的，不论是自动化测试平台还是云服务稳定性平台，都在已有平台基建的基础上，依靠LLM增强的AIGC能力，做了诸如XMind用例自动生成、用例步骤自主探索、RCA故障定位以及服务发布风险实时解读等有业务价值的能力。
要做出这样的产品，投入的研发人力也肯定不少，而在这个体系下，怎么分配不同的研发角色，既能让每个模块的同学专注自身能力研发，又可以形成有机结合让整个产品顺利运转起来，是产品架构迭代过程中时刻都要思考的重要问题。为此，这篇文章就简单聊下，如果要大力投入这类型的产品研发，可能需要哪些角色，以及其中可能存在配合是怎样的。
近期笔者因为参与LLM增强项目攻坚，对LLM工程相关的技术也希望有一定的了解，因此希望借这个机会，读一些文章充电，看看目前LLM智能化工程的一些研究趋势。在阅读了几篇文章之后，最终读者选定AgentFlow这个项目做代码实现分析。由于笔者在算法方面的涉猎实在不深，所以本文只是抛砖引玉，阐述上有什么不专业不严谨的地方，也辛苦大家指正。
AgentFlow主要解决现有LLM在进行工具增强推理时有可扩展和泛化能力差的问题，简单来说就是在线LLM-Agent服务缺乏在生产环境中RL（强化学习）的手段。所以AgentFlow提出了以下的解决方案，一是一套动态训练Planner的编排，另外一个是一套奖励目标训练算法Flow-GRPO。源码可以通过这个GitHub来下载，跑了一番看Agent编排的实现比较完整，但在线服务跟训练的部署执行会比较难搞，所以本文更倾向于对Agent编排做详细阐述。
Agent编排包含Planner、Executor、Verifier跟Generator四个角色，Planner会不断Rollout判断下一步要做什么，Executor执行ToolCall，Verifier判断当前问题是否解决，Generator负责整合Output。整个核心代码集中在Solver.solve，长这个样子：
作为国内表现上比较agentic的开发工具之一，trae项目开源了自家trae-agent开发工具，整体也有一段时间了。借着日常闲暇的机会，笔者计划研究下trae-agent的代码实现，看下这个本地AI开发辅助工具是如何运作的。
从开源项目的角度，trae-agent给的文档信息是比较充足的，但代码实现上只能说是MVP版本，只有一些基础功能。当然这个也可以理解，相信实际生产用的trae-agent会远比这个实现更加复杂，以及不可能所有人力都投入到开源项目的建设中。所以今天就简单看看这个项目的主流程。
在Game-Of-AutoTest系列的文章当中，曾经深入聊到如何做好游戏自动化测试的技术实践，包括用例编写和任务调度等多个方面。由于工作原因，笔者再一次需要了解自动化测试平台的整体架构，因此也借着这个机会，从更加宏观的角度，再聊一下自动化平台架构设计的一些通用要点。
十一国庆正是充电的好时机，借着假期时间充裕，笔者又浅调研了一下本地LLM开发相关的工具链，看下如果是日常业余搞个人LLM的Agent项目，具体有哪些能力可用。工业界的话，因为知识保密性等各种原因，我们可能会用到兄弟部门的LLM模型或者相关Agent能力，以及市面上收费但企业内部免费的一些技术基建。但如果是个人搞LLM应用开发，就更加倾向于看有没有低成本甚至免费的办法去做本地研发了。
基于这个目的，经过一番调研实操，发现只需要一个Agent开发框架加上模型Provider就能解决问题。因此本文就介绍一下，以Agent开发框架Eino，加上Ollama这个模型Provider，如何能够低成本研发LLM的Agent。针对这个主题，虽然以前也写过用Coze开源版研发的Case，但Coze本身作为一套工业界产品基建，直接拿它工作还是比较重的，本文暂且只讨论一些比较轻量的事情。
在三年前笔者撰写的Game-Of-AutoTest专栏当中，聊了很多关于游戏自动化测试的实践思考。不论是对自动化测试在技术层面的认识，还是怎么落地一些技术基建保障游戏自动化测试的可扩展性，在这些专栏里都已经做了深度的科普。近年来，LLM在自然语言处理领域取得了突破性进展，并且随着游戏开发的复杂度不断提升，自动化测试在保障游戏质量方面变得尤为重要。直感来看，LLM作为通用的信息处理转换大脑，必然能为游戏自动化测试技术带来了新的可能性。因此，本文就浅聊一下LLM赋能游戏自动化测试的一些想法。
变更风险防控的能力是多样的，除了最传统的告警检测、Metrics曲线对比以及自动化测试能力之外，像变更影响分析、风险降噪以及线上风险RCA等周边能力也是不可少的。有了更多的上下文信息，才能对变更风险做更好的判断。从中台技术视角来看，不论是传统能力还是一些AI加成的能力，如果没有一套稳固的技术基建让这些能力尽情发挥，那么这些能力将难以快速落地，充分兑现其业务价值。
基于此，笔者在今年工作中，交付了一套「能力市场」产品与技术架构，旨在面向不同业务团队的自研能力，提供一套开放式标准化的接入方案，让业务自研的变更防控能力可以快速应用到变更风险质检过程中。虽然这套架构目前还有很多继续扩展和完善的空间，并且也没有蹭到LLM的噱头，但在架构迭代过程中笔者权衡了很多利害关系，主导了很多技术演进判断，最终也成功落实了这个技术结果。
具体一些技术上的设计，其实前面的文章已经聊了很多，包括任务调度、事件状态机以及内置降噪模块嵌入之类的点都有阐述。所以今天这篇文章，不倾向于聊这些具体的技术实现，更倾向于聊下整个产品交付过程中的一些权衡和判断。
在先前的文章中，我们聊到了一个变更观测任务可以通过什么样的方式对不同的变更防控能力做统一调度，达到优越的变更风险拦截效果。但是在实战当中，变更观测任务集成了很多能力，即便风险拦截率很高，但不同能力效果也有差距，因此会有可能出现误报，导致变更观测结论不准确，影响研发发布效率。为此，一套成熟的变更观测系统，是需要嵌入一个决策降噪模块，通过干预变更防控拦截结果，达到在风险召回不劣化的同时，提升准确率，让结果更加置信。
因此，今天笔者决定结合自己的工作经验，简单聊一下变更风险防控架构的宏观体系当中，决策降噪模块应当怎样接入比较合适。需要说明的是，本文不涉及具体降噪的实现，包括算法的许多部分，主要是从后端工程架构角度，聊一下怎样的架构设计，能够让变更观测任务和决策降噪任务完美配合起来。