一匹马能跑多快是天生的，但这份马力能不能用在该用的方向上、该收的时候收住，靠的是那副马具。harness 本义就是马具——套在马身上、把马力传导到车上的那整套装备。放到 Agent 上，它指的是模型之外那一层代码：这一轮让模型看到什么、它提出的操作准不准执行、失败怎么回喂、任务断了怎么接上、最后凭什么说事情做完了。 全文按「一个循环 → 四个子系统 → 生产化 → 长时运行 → 评测 → 选型」展开。读完你大概能看出市面上多数 Agent 产品里，哪些部分是模型给的，哪些部分是有人一行行写出来的。
策略效果类Agent评测面临反馈信号稀缺、评估多维权衡、离线与线上效果脱节三大难题。文章提出"五层、四步、三阶段"方法论：五层评测对象（从Prompt约束到业务效果）明确"评什么"；四步质量归因（诊断、定位、优化、验证）解决"评完怎么办"；三阶段上线治理（准入、灰度、监控）回答"如何上线"。针对离线评测与线上效果对齐难题，创新性提出Auto Rubrics方法，通过三层架构构建可解释的业务效果Judge体系，有效规避位置偏差、选择过拟合等系统性陷阱，实现策略效果的可信评估，为策略类Agent规模化落地提供质量保障。该方法论将评测从静态判断转变为动态闭环，确保策略生成能力真正可扩、可控、可回归。
最近手里一个项目要用消息队列，正好赶上它接入 AI 这件事，然后我把 RocketMQ 重新捡起来研究了一下。五月底发布的 RocketMQ 5.5.0，把专门为 AI 场景设计的 LiteTopic 消息模型放进了开源版本，也就是社区提案 RIP-83 里定义的那套东西。我之前用 RocketMQ，跑的都是订单、日志这一类传统场景，这次看到官方针对 AI 负载专门做了消息模型，还顺手把 MCP、A2A 这些智能体协议的支持也做了，就花时间把官方文档和代码都翻了一遍。先说清楚一个容易误会的地方，RocketMQ 接入 AI，它自己并没有变成大模型，干的还是消息队列的老本行。变化主要在这套新的主题模型上，它是照着 AI 应用的通信特点做出来的。另外 LangChain、CrewAI、AutoGen、Dify 这些主流 Agent 框架也都能对接。这篇文章就说两件事：它是怎么接入 AI 的，以及对比以前的 RocketMQ，到底多解决了哪些问题。
最近各个厂商都在深入研究多智能体协作。让多个智能体工协作，各自负责一块任务，共同完成一个复杂目标。听起来逻辑很通，一个智能体搞不定的事情，多叫几个一起来干不就行了？但真正搭过的人都知道，这里面的水比看上去深。系统跑起来了，效果却未必好，有时还不如单个智能体单独干。问题出在哪？是模型不够强，还是提示词没写好，或者根本没有一套可遵循的最佳实践？
Kotlin Serialization 框架通过 @Serializable 注解提供自动序列化功能。与 Gson、Moshi 等基于运行时反射的框架不同，Kotlin Serialization 在编译期生成序列化代码，因此在类型安全、运行性能和混淆兼容性方面具有天然优势。在控制序列化格式、处理第三方类或实现动态序列化策略等高级场景中，仅靠注解往往无法满足企业级需求。本文将系统性地介绍如何创建、绑定和使用自定义序列化器，涵盖从基本实现到高级上下文序列化的完整知识体系。全文在讲解 API 用法的同时，会适度展开编译期与运行期的协作机制，以帮助开发者建立更稳固的工程化认知。
多 Agent 工作流里，真正拉高 Token 消耗的往往不是代码本身，而是长上下文在多轮请求中被反复携带。本文结合轻量云的一次真实研发实践，拆解如何通过渐进式加载、响应级批量和批量编辑工具减少不必要的模型往返。
