2026
10月
09月
给 AI 的记忆分个层：上下文数据库的设想
AI编程助手的长期记忆问题核心在于现有方案（如向量数据库、RAG管线）缺乏有效的组织结构。作者提出"上下文数据库"概念，将其类比为虚拟文件系统，通过层级目录树整合长期记忆、项目知识和可复用技能。关键设计包括三级摘要结构（L0概括/L1要点/L2原文），在检索时逐层筛选以降低token消耗，并通过目录感知检索保留知识结构。当前挑战包括摘要一致性维护、粒度划分和自动化写入路径，需在小规模验证检索有效性后再优化写入流程。该方案强调知识的结构化组织和token使用效率，区别于传统扁平化检索的碎片化问题。
把发布博客做成一条命令：我的 Halo 自动化流水线
这篇博客详细记录了作者将博客发布流程从手动网页操作逐步升级为全自动脚本的优化过程。核心内容包括：（1）自动化的核心价值在于将人为失误转化为可控的脚本错误，通过密钥管理、六步流水线（导入、元数据更新、备份、回填、验证、归档）实现稳定发布；（2）关键设计采用清单驱动和固定slug策略，尤其强调验证环节需检查发布时间、正文一致性及资源可用性；（3）实战中遇到的乐观锁冲突、CDN故障和DNS劫持三个典型问题的解决方案；（4）明确自动化边界，保留选题、封面审核和通读等需人性判断的环节。最终实现单命令发布，将节省的时间反哺内容创作，体现自动化"防错优先于省时"的本质。
有了 Flowable，为什么还写了个编排引擎
本文阐述了自研Agent工作流引擎的设计原理，与Flowable审批流的本质差异在于处理秒级模型调用链。核心设计包括：1. 采用JSON定义DSL，通过nodes和edges分离控制流与数据流，节点类型封闭但配置开放；2. 校验阶段通过BFS/DFS检测孤立节点和环路，预防执行时资源浪费；3. 执行时通过上下文变量实现节点间数据传递，条件分支依赖运行时数据而非图结构；4. 特殊设计APPROVAL节点支持短时人工审批，与Flowable形成时间尺度互补；5. 模板解析功能实现零阻力数据引用。该设计使业务人员能通过配置搭建AI服务链路，验证了引擎抽象的价值——Flowable处理天级人工审批，Agent引擎处理秒级模型协作，两者在系统中各司其职。
AI 助手是怎么回话的：Agent 任务的异步执行链路
本文解析了企业IM系统中AI助手回复消息的全链路设计。核心挑战在于同步调用大模型会导致系统阻塞、重试重复和排查困难，因此采用异步任务化方案。关键设计包括：通过独立事务和事务提交后投递确保任务落库与执行隔离；任务状态机和配置快照保障执行幂等性；工作流与单轮对话双执行路径；基于幂等键和结构化审计的故障处理机制。该架构实现了三类保障：通过事务边界控制避免数据库连接泄漏，通过状态检查防止重复执行，通过超时扫描解决长期卡死任务。最终形成包含8个环节的完整流水线（落库、认领、快照、执行等），使AI能力能安全集成到企业系统，同时保持全过程可观测性。
把 AI 放进审批流：先教它说"我不知道"
该文章探讨了AI预审在审批流程中的核心设计原则与实践。通过三值决策（APPROVED/REJECTED/TO_HUMAN）为模型设置"不确定"出口，显著降低错误率；采用输出重建机制（容忍格式噪音、字段级补全、决策白名单归一）确保下游获得结构完整的保守决策；设定超时驳回规则避免系统故障导致资金冻结。核心在于：AI功能需实现无单点依赖的优雅降级，模型输出需被视为不可信输入严格处理，所有设计均导向"宁可转人工也不错误放行"的失效安全方向。最终预审系统在减少人工初审工作量的同时，通过决策可视化建立起审批人对AI建议的可信度校准机制，且未发生误驳回投诉。
假期余额怎么做才不出错：冻结、扣减与幂等的账务模型
本文分享了在人事系统设计中构建假期余额账务模型的关键方法。核心解决方案包括：1）将余额拆分为可用与冻结字段，通过三段式流程（冻结-扣减/解冻）确保额度归属明确；2）采用四类流水记录每次变动并保存变动后余额，实现操作可追溯；3）通过行锁+乐观锁双重机制处理并发修改；4）设计带指纹校验的幂等键，区分正常重试与数据冲突。文章特别强调，系统需保留对历史无冻结记录单据的兼容处理，并指出分账机制、流水追溯和严格幂等校验是保障账务型功能可靠性的通用原则。这些方法适用于余额、积分等需要精确原子操作的场景，重点在于确保异常情况下数据仍能对账。
密钥别再写进配置文件了：一次 macOS 钥匙串集中管理实录
本文介绍了将敏感密钥从明文存储的`.zshrc`迁移至macOS钥匙串的方法，以提高安全性。作者发现明文密钥存在备份泄露、截图暴露和权限过宽（如644）等风险。解决方案是通过`security`命令实现双层次管理：钥匙串加密存储密钥，shell启动时读取并注入环境变量。关键技巧包括避免使用`-w`参数防止`ps`暴露密钥、处理特殊字符转义，以及区分终端和GUI应用的不同管理模式。最终效果是消除了配置文件的明文密钥，并通过审计脚本验证安全性。文章强调本地文件并非绝对安全，并提醒注意进程参数泄露等隐蔽风险。（215字）
让 AI 查数据不能只靠嘴：Agent 工具调用的安全边界
本文探讨了AI助手工具调用功能的安全设计要点。核心思路是通过显式枚举工具白名单、严格控制数据权限、强化参数校验确保安全性。具体措施包括：1）用switch-case静态定义工具路由，拒绝反射动态调用；2）复用业务系统的"本人或直属下属"权限规则，严防跨用户数据访问；3）参数处理容忍数据类型差异但严格校验必填字段；4）返回值通过字段白名单控制数据暴露范围；5）采用模块解耦设计保证基础功能可用性。实践证明，在确保零越权的前提下，该架构能稳定支持每日数百次员工信息查询。关键启示在于：AI能力的可信边界需通过工程化手段固化，工具执行器本质上是通过代码约束实现的"能力海关"。
密码连错五次锁半小时：用 Redis 给登录接口加防爆破
作者发现内部系统登录接口无频控措施，存在密码爆破风险。基于Redis设计了一套失败锁定方案：以`userType:loginName`为Key，5次失败触发30分钟锁定，首次失败设置TTL，并在登录流程的三个节点（前置检查、失败计数、成功清零）接入频控。该方案避免了内存存储的多实例同步、数据丢失问题，但需注意三个关键细节：1) INCR与EXPIRE需原子化操作防永久锁定；2) TTL从首错算起可能导致实际锁定时长波动；3) 账号锁定可能被反向利用，需确保独立于登录的密码找回通道。作者指出，频控本质需权衡安全与体验，明确锁定语义比实现技术更重要。
