嘿嘿嘿嘿，感谢 Olivia 的到来，带来好产品和大家分享~ 期待一起在 @Solana_zh Build！（BTW，感谢 @PANews 和 @PresleySun 的龙虾活动让我们相遇哈哈哈

前一段时间我摸索出了一套 AI coding 的工作流（之前这条推里提过： ）， 但在真正用的时候发现，并没有一个工具能非常完整地贴合这套流程，于是干脆自己顺手做了一个。 我的核心诉求其实很简单： 我已经把需求和方案写成了 issue，我希望一个工具能直接拿到这个 issue，把事情做完，然后给我一个 PR 让我 review。 如果我在 review 里提了 comment，希望它能再跑一遍，把问题修掉，并且逐条告诉我它是怎么修的。 于是就有了 holon。 用法也很直接： holon solve github_issue_pr_url 如果是一个 issue，它就直接解决并提交 PR； 如果是一个 PR，它就去修 review comments 或 CI 错误，然后再提交。 holon 也可以配置成 GitHub workflow，只要在 issue 或 PR 下面评论 holonbot，就会触发它去提交 PR，或者修已有的 PR。 整个 holon 工具本身，就是用这套流程写出来的。 我先写 issue，然后 holonbot 开发，开发完让 copilot review，review 的结果出来以后，再让 holonbot 修复，我只负责最后合并代码。 大概一周多的时间，合并了 200 多个 PR，close 了 150 多个 issue。 只有在 holon 把自己改坏的时候，才需要我亲自下场修。 大多数 PR 我其实不会细看代码，主要看的是 copilot 和 holonbot 在哪些地方产生了分歧，看看他们在争论什么点、为什么会争论这些点。 有时候我会补一两个 review comment，但也不是每次都会被接受，偶尔还会被 holonbot 直接驳回😅。 后来发现有一类 review comment，比如需要补测试、或者需要比较大的重构，其实不适合当下直接修，于是干脆让 holon 在这种情况下自动创建一个 issue，把问题记录下来，等未来再处理。 整体体验还是比较丝滑，项目在这里： 欢迎大家在自己的项目里试一试，有问题可以直接提 issue，让 holonbot 来修。

昨天才在看 Agent 编排器，顺手写了个阅后笔记： @_kaichen 师这个推荐！马上开始 dd opencode！ღ( ´･ᴗ･` )

🧑‍💻由Solar和 @solana @solana_devs 举办，@magicblock 支持的2026 Solana技术训练营AMA明天开启 🗓️1月2日 周五9pm HKT 1月6日开始线上授课，你准备好了吗？开营AMA聊聊技术训练营要准备的一切：课程设置、如何上课、社区支持、课后挑战、毕业奖励等等 嘉宾🎙️ @Mikkke_crypto @deanmlittle @tibetanwater @shirleneliu69 @0xqiuqiuu @sgshumin @tinyxiong_eth 抓紧时间报名，搭上Solana生态工作招聘直通车👉

x402 v2 发布，这不是一次简单升级，而是把 x402 从「一套实现」，推进为「一套可演进的标准 + 可插拔的参考实现」。让 x402 不再只是一个 SDK，而真正像一门互联网原生的付费接口语言。 在 v1 时代，x402 的模型非常简单： 服务端要钱 → 客户端签名并支付 → 服务端验证 → 结算完成。 这个模型很好理解，但也非常“直线”。 一旦你需要更多网络、更多支付方式，或者更复杂的结算形态，你很快就会走到 fork SDK、打补丁、私下维护协议边角的路径上。能跑，但生态很难协同演进。 x402 v2 的核心变化可以压缩成一句话： 它把“变化”从核心协议里移了出去。 变化不再通过“改 spec / 改 core”引入，而是被明确安放在 Extensions、插件式机制（mechanisms）和生命周期 hooks 中。 这一步非常关键，因为它决定了生态中的新能力，能否在不修改核心协议的前提下并行演进。 在这个前提下，v2 的几项变化可以被更好地理解。 首先是协议层：x402 变得更加 HTTP-native。 402 的语义回到 402，本该标准化的支付元数据进入 header； 应用层可以自由返回 HTML paywall、JSON 或任意 body，而中间件和 facilitator 依然可以稳定处理支付语义。这让支付协议第一次真正适配了现有的互联网基础设施。 其次是架构层：SDK 引入了注册制和生命周期 hooks。 支持新网络、新 scheme，不再需要往 core 里堆 if/else，而是实现接口并注册。 hooks 为策略性逻辑提供了官方入口，但核心 SDK 本身被收敛为“流程编排者”，而不是业务能力的承载者。 再往上一层，是 Extensions 的意义。 v2 为生态提供了一个标准化的“可选能力槽位”。 像 Discovery、Identity，以及 Settlement Router / Programmable Settlement 这类能力，都可以通过 Extension 被声明、被协商，并逐步形成共识。 服务端可以声明它支持哪些扩展，facilitator 可以声明实现了哪些扩展，客户端也可以据此选择或组合——这才是一个标准能够长期演进的方式。 在这个背景下，再看 x402 v2 对 x402x 的意义。 x402x 是 Settlement Router 这一类扩展的一个具体实现。 它通过一个 SettlementRouter 链上合约，提供了原子化、可编程、可组合的链上结算路径： 结算可以被路由到多个 recipient，可以原生支持分账和抽成，也可以与通过合约 Hook 和其他链上合约无缝组合——例如 token mint、DeFi 调用，或其他基于链上状态的结算逻辑。 在 x402 v1 时代，这类结算能力往往需要 hack 核心协议，引入特殊的路由处理逻辑； 而在 x402 v2 中，借助 Extensions 和注册制机制，它们第一次可以以标准扩展的形式存在，而不是以 fork 的形式存在。 这带来的变化是结构性的： x402x 的价值不再来自实现路径本身，而来自它所表达的结算语义，以及这些语义在链上合约生态中的可组合性。 总结： x402 v2 让“付费 API”第一次具备了互联网规模化协作的结构条件。 而像 x402x 这样的结算扩展，也终于可以在这个标准框架内生长——不需要 hack 核心协议，而是作为 Extensions，被选择、被组合、被演进。

感谢 @SkylerMiao7 的引荐。我们很高兴与 @minimax_ai 联合推出基于 MiniMax M2-Stable 模型的一站式 Vibe Coding 平台，现开启公测。平台覆盖从开发、部署到盈利分析的全流程，诚邀大佬们体验。👉 #VibeCoding# #AI4Dev# #MiniMax#

理解 @daydreamsagents 的agent-kit 🧵 理解 agent-kit：为 AI Agent 构建可发现的服务 1️⃣ 引言：它解决什么问题？ 传统 API 是为人类开发者设计的。 AI Agent 面临四个痛点： 1）找不到服务 2）不理解输入输出 3）不会自动支付 4）无法判断信任 agent-kit 的目标： 让 AI Agent 能像人一样「发现 → 理解 → 支付 → 调用」服务。 2️⃣ 想象一个 AI Agent 的理想流程 👇 3️⃣ 所以一句话概括： agent-kit 让你的服务能被 AI Agent 自动发现、理解和调用。 传统 API：人类 → 文档 → 集成 agent-kit：Agent → Manifest → 自动支付 → 调用 4️⃣ ❌ agent-kit 不是什么 不是 LangChain、AutoGPT 那种「Agent 框架」 不提供 LLM 推理、决策 不帮你创建“思考的 Agent” 5️⃣ ✅ agent-kit 是什么 它是 Agent-to-Agent (A2A) 服务框架： 帮你创建 被 AI 调用的服务 1. 提供自动发现 (manifest) 2.内置支付 (x402+ AP2) 3.内置信任 (ERC-8004 + A2A) 换句话说： 你写的不是 AI，而是 AI 可以用的 API。 8️⃣ 架构三层图 🧩 9️⃣ agent-kit 核心组件： Hono App（轻量 HTTP 服务器） Entrypoint Registry Manifest Generator Middleware（支付、验证、执行、响应） 🔟 请求流程： 发现阶段： Agent 调用 GET /.well-known/agent.json → 获得服务能力描述 调用阶段： Agent 发送 POST /invoke/:key 附带 Payment-Hash（x402 支付凭证） 11) 内置功能 1️⃣：服务发现 自动生成 manifest，描述服务能力、输入输出、价格。 Agent 无需文档阅读即可调用。 12)内置功能 2️⃣：x402 支付协议 基于 HTTP 402 状态码的标准化微支付机制。 AI Agent 自动完成： 查询价格 通过 facilitator 支付 附带支付凭证调用服务 → 实现全自动加密微支付。 13) 内置功能 3️⃣：ERC-8004 身份与信任 提供链上身份、声誉系统、可验证注册信息。 让 AI Agent 能判断「这个服务靠谱吗？」 14) 内置功能 4️⃣：Zod Schema 验证 输入输出类型安全 自动生成 JSON Schema 明确错误信息 TypeScript 类型推导 AI Agent 可以通过 manifest 理解接口结构。 15) 内置功能 5️⃣：流式传输 (SSE) 适合长任务： 可通过 实时推送进度。 16) Entrypoint = Tool 每个 entrypoint 在 Agent 视角下就是一个可调用工具。 LangChain/Claude 可以自动读取 manifest → 注册为工具。 17) 好的 Entrypoint 设计： ✅ 原子化：一件事一个入口 ❌ 不要“大而全”的万能接口 18) 对比传统框架 🧠 19) 总结 🌐 agent-kit 的核心价值： 自动发现\自动支付\类型安全\信任体系\简化开发 💡 一句话收尾： agent-kit = 让 AI Agent 能「发现、理解、支付、调用」你的服务的标准化框架。