近期大模型Agent应用开发方面，MCP的概念比较流行，基于MCP的ToolServer能力开发也逐渐成为主流趋势。由于笔者工作原因，主力是Go语言，为了调研大模型应用开发，也接触到了mcp-go这套MCP的SDK实现。
对于企业内部而言，在这个SDK基础上做封装，基本上就能够完善MCP-Server的开发生态。因此今天就简单看一下这个SDK里面，实现了什么东西。
首先是Client连接的实现，这里可以看到每次连接都需要InitializeRequest、InitializeResult以及InitializeNotification这三次握手。从Client角度看逻辑是这样：
最近在AI大模型领域，MCP这个概念非常火，大大小小的公众号都开始对外炒作这个概念，宣教一种新的大模型Agent开发生态。因为工作原因，近期笔者也对MCP和LLM-Agent开发做了一些接触。因此今天这篇文章就浅聊下笔者对基于MCP的LLM-Agent开发方面，自己粗浅的一些理解。
首先还是聊一下什么是MCP，以及MCP在LLM-Agent开发方面，解决了什么问题。
在先前的文章当中，笔者分享了一套简洁的go微服务monorepo代码架构的实现，主要解决中小团队协同开发微服务集群的代码架构组织问题。但是在实际代码开发过程中，怎么组织不同的业务服务service实例，就成了比较棘手的问题。
为什么会出现这样的场景？首先，不同的业务服务可能会用到相同的底层服务，比如DB、缓存、MQ以及三方Client等等。其次，一个底层服务实例可能会在多个业务服务复用，一个业务服务又可能成为另外一个业务服务的依赖。因此这样下来，不同服务实例之间就存在错综复杂的联系，用代码组织起来就比较困难了。
幸运的是，我们拥有wire工具去做go对象的依赖注入，这样就可以用简单的代码实现解决上述问题。在以前的wire文章当中，也简单提到了wire对于微服务框架的作用，但讲解的不算特别精要。所以今天这篇文章，笔者就分享下在go大仓的场景下，怎么用wire去解决service实例依赖问题的，以及怎样才是更加恰当的打开方式。
首先我们要知道wire工具对外暴露了什么能力，有以下一些：
在研发测试日常工作中，通常会遇到很多琐碎的事情，占用我们工作的时间和精力，从而导致我们不能把大部分的注意力放在主要的工作上面。为了解决这个问题，除了加人之外，我们通常会开发一些日常用的效率工具，比如以pyqt、pyside为主体的桌面应用，一键化我们的日常工作，从而解放我们很多处理琐碎事情的精力，让我们有更多精力打磨主业，创造更好的工作成绩。
因此，本文就分享下笔者在24年下半年调研学习pyside6的一些成果，把自己做的小应用homemade-toolset开源出来，供各位有需要的同学参考学习。
整个项目包含时间转换工具、JSON工具以及类似Postman的Request工具，采用python3.11和pyside6开发，目录结构如下：
在先前的文章中，对于变更风险观测的流程逻辑设计，有浅谈一小部分。但从宏观来讲，一个变更观测平台，需要对大量的观测任务做统一调度，这样才能把整个观测平台给支撑起来。因此，本文就简单分享一下，变更风险观测的任务调度可能怎样设计。
这个问题可以拆分为几个子问题：多任务并发需要如何处理，任务调度的消息协议需要如何设计，以及怎么去保证整个调度系统的稳定性。
近期因为项目架构升级原因，笔者着手调研一些go项目monorepo的代码架构设计，目标是长期把既有微服务项目重要的部分都转移到monorepo上面，让代码更容易维护，协作开发更加方便。虽然经验不多，但既然有了初步的调研，今天就分享一下笔者所面临场景的monorepo设计思路。
从语言特性上讲，Golang是非常适合做monorepo的，但根据不同项目研发需要，monorepo的目录结构可以定制成不同的形式。所以要做monorepo，首先要回答的问题是，做这个事情主要解决什么研发问题，优化了什么东西，否则投入量过多，ROI就会很低。
从质量管理角度来讲，变更风险防控算是一类重要的方向，从业务的角度来讲，通过运营变更风险数据，可以更好了解变更发布的质量，从而预防线上问题。今天就浅聊一下，变更风险防控的数据运营，需要做好哪些数据基础。
简单来说有以下三个部分：渠道风险、准召拦截、发布效率。
技术人培养产品思维，这一点是技术人在职业成长中不可缺少的一部分。无论是做业务开发，还是做纯粹的基础架构、技术优化，有了产品意识，才能把自己的技术作品打磨地更好，能在更多工作场景派上用场。那么，今天就聊一下作为技术人，有什么方式可以提升产品意识。
把这个问题丢给AI，概括一下答案是几大块：第一块是学习产品知识，比如阅读相关产品设计书籍，参与课程讲座；第二块是深入了解用户需求，培养用户视角；第三块是加强跨部门沟通，和其它团队紧密合作。AI给到了很好的一套思维框架，帮助我们技术人找到一些提升产品意识的路径，但具体怎么做，最终还是要结合咱们自己的经历来。所以今天，就分享一下个人经验。
在线上服务变更过程中，我们希望可以通过一套实时观测机制去监测线上服务的风险，从而能够确保线上稳定性，在出问题时可以及时回滚变更。今天这篇文章，就简单讲一下变更风险观测的流程逻辑需要怎么设计。
首先我们需要建模变更观测的过程。变更观测的生命周期，一般来讲，当服务某阶段变更开始后，观测会开始，然后当服务某阶段变更完，一般还需要停留观察一段时间，确定线上没有遗留风险之后，观测才会结束。可以简单的认为，一次变更观测，关联一次发布的某一个过程。所以一个观测任务，结构数据上需要包含发布工单的元信息、观测参数的元信息，以及任务自己的运转状态，同时每个任务实例需要被有序的调度起来，因此所以要有一个调度系统去处理每个任务实例的状态推进。
然后，再细一个粒度，对于一个特定的变更风险点，我们也需要用一个特定的观测能力去cover，所以对于每个观测能力，也要和上层的观测任务一样，有自己的元信息和状态转换定义。任务对能力是一对多的关系，一个观测任务当中，可以通过某种编排，把不同能力在不同的时间点启动起来，切入到发布过程的不同时机，这样就能够形成灵活的变更观测。
从这些角度出发，以一个简单的串行思维，整个变更观测任务需要做以下的动作：
作为程序员，脑力劳动者，保持一个健康的身体，是非常重要的。回顾24年自己取得的结果，一个比较亮眼的就是减肥减了10kg，到达了一个比较健康的体重，保持了半年没有反弹，当然到现在也依然在保持。今天这篇文章就给大家分享一下自己的减肥和体重保持的经验。
减肥的要领，主要包括以下几点：心态、吃、运动以及休息。