同样是 GPT-4 或 Claude，有人做的 Agent 稳定可靠，有人做的却频繁翻车。我最近在学习 Agent 工程化，把这个问题从头到尾理了一遍，发现问题不在模型本身，而在**模型之外的整个系统**，也就是 Harness。

旧版 MCP 跑 demo 没问题，一上生产就是无法集群、无法扩容、无法上线、无法规模化。2026-07-28 官宣的规范把 session 握手整个废弃，协议变成无状态自描述。我把它当成一次推翻底层架构的重做来看，不是加功能。

Pi 六个设计逐一拆源码：声明合并扩展消息、Turn 热切换模型、双队列分打断与追加、工具级 AOP、压缩带文件索引、工具自主停止。

Node 从零做只读 MCP 服务：我把“AI 读私有代码”这件事做歪了两次，才收成一个能跑、能搜、但不至于乱来的最小版本

很多人第一次看到 `LiveComponent`，直觉都会觉得：“哦，组件复用方案。” 这话不能算错，但只说这一句，基本等于没说。因为我自己一开始也栽在这儿了：把能拆的都拆成 `LiveComponent`，结果代码没变清爽，反而把 `update/2`、`handle_event/3`、父子通信、列表更新全搅成一锅粥。后来我才慢慢想明白，`LiveComponent` 真正值钱的地方，不是“能复

本文分享了一个正在开发中的垂直 SaaS 项目——Pico-CRM（家政版），聚焦家政/到家服务场景下的客户到履约核心闭环。技术栈采用 Rust 全家桶（Leptos + Axum + PostgreSQL），在 MVP 阶段做出了一系列务实取舍：业务主线优先于功能广度、多租户先做轻隔离、角色权限早定义、看板指标以高频为优先。文章结合实践体感，探讨了做垂直 SaaS 时“把最值钱的主线跑通”的核心

传统 CRUD 用 `status` 字段存订单状态，旧值直接覆盖，出了纠纷谁也查不到。本文记录了我用 Rust + disintegrate 给家政 CRM 订单模块重构为事件溯源的完整过程：用事件序列替代状态字段、用 Decision 模式集中业务规则、用 State 投影还原当前状态。包含真实代码示例、踩坑实录（时序问题、调试复杂度）以及意外收获（事件流天然 = 审计日志）。

用 Rust 写前端是一种什么样的体验？本文以 Pico-CRM 为例，分享 Leptos SSR + WASM Hydration 在真实项目中的一年实践——从 context 跨边界注入、Server Function 的双重身份、第三方 JS 库的 hydration 时机之争，到 `thread_local!` 全局弹窗的骚操作。不是教程，是一个全栈独立开发者的踩坑实录。

在 Rust 全栈项目里实现文件上传，最麻烦的不是后端 S3 对接，而是 WASM 前端怎么把用户选中的文件读进内存。本文拆解 Pico-CRM 从浏览器 FileReader → JsFuture 异步读取 → Leptos Server Function 跨边界传输 → 领域层分类校验 → S3 兼容网关落盘的完整链路，附带 `Rc<RefCell<Option<Closure>>>` 闭包生

给家政 SaaS 做权限模型，没有用 RBAC 库也没有上 CASL，四个角色（admin/merchant/operator/user）、两条中间件（页面重定向 + API 拦截）、Cookie HttpOnly + HS256 签名，全部在 Axum 和 Leptos 里手写落地。本文从角色定义、JWT 签发、中间件双通道设计、前端菜单驱动四个层面拆解实现细节，分享"不做过度抽象"的权限设计思