Ponytail：把 YAGNI 写进 Coding Agent 的行为层
Ponytail 带着明显的玩笑式包装：为 AI 编程代理配置一组“懒得过度设计”的资深工程师偏好。再往下看，它解决的是一个更具体的工程问题：当模型默认倾向于多写文件、多引依赖、多造抽象时，怎样在代码生成前插入一层可重复执行的复杂度刹车。 截至 2026-06-17，DietrichGebert/ponytail 的 main 分支最新提交是 45f7d2f，公开 README 已经把项目定位成一个跨宿主的 Agent skill 分发包。它不是传统意义上的库，不提供业务 API；核心资产是一组行为规则、宿主适配器、生命周期 hook、模式切换命令，以及配套 benchmark。 Ponytail 不是少写代码提示词 Ponytail 的核心规则放在 skills/ponytail/SKILL.md。这份 skill 的主线是一条六级阶梯： 123456需求是否必须存在 -> 标准库能不能解决 -> 平台原生能力能不能解决 -> 已安装依赖能不能解决 -> 能否一行完成 -> 末端才写最小可用实现 这条阶梯的意义不在于“让模型懒一点”，而...
Loop Engineering：从 Boris 的 /loops 到持久 Agent 工程
本文的 Loop Engineering 取工程视角：持久 Agent 自动化的工程抽象，包括定时触发、长期运行、多会话并发、可恢复状态、权限边界、验证证据和人工升级路径。Claude 官方在 Getting Started with loops 里给出的 4 种循环分类（Turn-based / Goal-based / Time-based / Proactive）是操作视角的互补坐标系，见后文「循环的 4 种触发形态」。 本文与已有文章的边界 本博客已有 Agent Loop、Ralph Loop、Goal、Harness Engineering、Hook 体系等相邻文章，本文专门讨论 Loop Engineering。和已有文章的边界： 已有文章 主要讨论 与本文的关系 AI Coding Agent 的 Hook、Loop 与插件体系 Codex、Claude Code、OpenCode、OMC 的运行时结构 写到 loop 与 hook，但没有以 /loops 和 Routines 的持久自动化为主线 持久 Agent：当任务活得比会话长 持久...
一次 AI Coding Agent Turn 的上下文生命周期：Hook、Tool、Skill、Compact 与 Subagent
一次 agent turn 不是一次模型调用。用户提交一条消息以后，运行时可能先补项目规则和 Skill 目录，再发起模型请求；模型返回工具调用，权限层批准或拒绝，工具结果追加回历史，模型随后继续判断。这个小循环可以重复很多次，直到验证通过、需要用户输入，或者运行时决定停止。 因此，理解 coding agent 的运行时，不能只看 observe -> act -> observe。还要追踪每一类信息何时进入上下文、以什么身份进入、何时失效，以及 compact 和 subagent 怎样改变信息边界。 讨论范围限定为一次 turn 的上下文生命周期。Skill 的跨产品加载差异见 AI Coding Agent 的 Skill 加载机制深度解析，messages 的追加、裁剪、摘要和外化见 上下文管理全景，MCP、A2A 与 AG-UI 的协议分层见 Agent 互操作协议全景。这里不再重做产品图谱，只保留能解释当前 turn 的官方机制。 Turn 的边界 在本文中，turn 从用户输入进入运行时开始，到主 agent 产生一个对用户可见的最终结果或明确停在阻...
Agent 互操作协议全景：MCP、A2A、AG-UI、ANP 和 Agent Runtime 的分层地图
两篇文章的最终定位 这组文章按一条边界切开：A 文讲外部接口和生态分层，B 文讲内部控制面。A 文回答“Agent 如何和工具、数据、其他 Agent、用户界面、观测评估系统相连”；B 文回答“一个 coding agent 在本机如何循环、拦截、授权、扩展和复盘”。 内容 放在 A 文 放在 B 文 MCP / A2A / AG-UI 作为三类互操作协议，分别解释工具上下文、Agent 间协作、Agent 与 UI 同步 只讨论它们进入 runtime 后如何变成 tool、server、permission、trace ANP / AGNTCY ACP / LMOS / Agora / AITP / agents.json 补全协议生态：去中心化网络、Agent 互联网基础设施、全栈平台、元协议、Agent 经济、Web 发现 不涉及 OpenAI Agents SDK、LangGraph、Google ADK、CrewAI、AutoGen/AG2、LlamaIndex、Semantic Kernel、Pydantic AI、Mastra、Strands...
深翻页的本质：从 RDBMS 到 ES 和 Hive
分页通常是一个很安静的接口参数：page_no、page_size，或者 limit、offset。数据量小时，它几乎没有存在感；等列表长到几十万、几百万行之后，同一条 SQL 只是把 OFFSET 往后挪了一点，延迟却会突然变得难看。 问题不在“翻页”这个动作本身，而在系统被要求从一个有序结果集里跳过很长的前缀。RDBMS、Elasticsearch、Hive 的表现各不相同，底层代价却很接近：先把前面的候选算出来，再把它们丢掉。 这也是深翻页最容易被误解的地方。它不只是 SQL 写法问题，还牵涉访问路径、排序稳定性、产品交互，以及底层系统是否需要跨节点合并结果。一个可用的分页方案，往往先从产品语义开始，而不是从 LIMIT 990000, 1000 开始。 深翻页的成本来自“计算前缀再丢弃前缀”。优化要么把前缀变窄，要么把“第 N 页”改成“从某个锚点继续”，要么提前把结果集物化成可跳转目录。 一个大表实验 有一个很典型的大表实验：表里大约 1000 万行，按 status 过滤后命中约 100 万行。测试环境是本地硬盘，慢查询阈值按 100ms 估算。几条查询的结果很...
Agentic Flow 不是 Harness：控制流、运行时与全栈研究模型
Agentic Workflow 的讨论里，Flow 是一个多义词，比 Harness 更容易被误用。 本文里的 Flow 不是某个框架的官方统一术语，而是一个作者抽象。它把 Anthropic 和 LangGraph 所说的 workflow、OpenAI Agents SDK 所说的 orchestration、CrewAI 的 Flows、Google ADK 的 graph-based workflows，以及研究实验里的循环、路由和门禁，统一放到“控制流规格”这一层讨论。 这个限定很重要。CrewAI 的 Flow 是产品概念；OpenAI 文档谈的是 agent orchestration；LangGraph 和 ADK 更常使用 workflow、graph、node、edge 这组词。它们不是同一个标准术语，但都触及同一个工程问题：任务的入口、路径、分支、循环、状态和终止条件，应该留在提示词里，还是成为可检查、可复用、可恢复的控制结构。 Harness 像运行时底座：它负责把模型、工具、文件系统、权限、日志、状态、检查点和评测装进一个可控环境。Flow 像控制规格...
持久 Agent：当任务活得比会话长
聊天式 agent 的生命周期等于一次会话：用户发起，模型循环，产出结果，上下文丢弃。持久 Agent（persistent agent / durable agent）指的是另一类系统：它承接的工作生命周期长于单次模型调用、长于单个上下文窗口、长于单个进程，甚至长于发起它的那台设备。 一个夜间跑依赖升级的 agent、一个跨三天迁移代码库的 agent、一个每周整理 issue 的 agent，都属于这一类。它们的共同点是：任务的时间尺度和会话的时间尺度脱钩了。这篇文章给「持久」下一个可操作的定义，并整理支撑它的三根支柱。 本文与已有文章的边界 已有文章 主要讨论 与本文的关系 ReAct：推理与行动交织的 Agent 循环原型 单条轨迹内的推理-行动循环 ReAct 是内环，本文讨论内环之外怎么让任务活下去 Agent 全景指南 Agent 范式演化与高可用 提供范式背景，本文聚焦持久性这一个维度 Goal 模式深度研究 完成谓词、循环停止条件 完成谓词决定持久任务什么时候可以死 Harness Engineering：长程 Agent 的工程化底...
ReAct：推理与行动交织的 Agent 循环原型
2022 年 10 月，Princeton NLP 和 Google Brain 的研究者在 arXiv 提交了 ReAct（arXiv 2210.03629，后被 ICLR 2023 接收）。论文标题是 Reasoning 和 Acting 的合成词，核心主张只有一句：让语言模型在同一条轨迹里交替生成推理（thought）和动作（action），推理指导动作，动作把外部世界的信息带回推理。 今天所有 coding agent 里那个「调用模型、执行工具、读结果、再推理」的内环，谱系都能追到这篇论文。理解 ReAct 的设计动机和它当年的实验边界，是理解现代 agent loop 的前提。 本文与已有文章的边界 已有文章 主要讨论 与本文的关系 Agent 全景指南 Agent 的必要性、范式演化和高可用落地 提供 Agent 范式全景，本文补上循环范式的论文源头 Harness Engineering：长程 Agent 的工程化底座 长程 Agent 的工具、状态、验证环境 Harness 包在循环外面，本文讲循环本身从哪来 环境可供性：智能的一半是取到...
企业微信能自动加好友并拉群吗：官方 API 能力边界与架构方案
结论先放在前面 截至 2026-06-06，企业微信官方 API 不能完整实现“企业后台自动把商铺业主和普通用户加为好友，然后主动把他们拉进群”这件事。 一个容易混淆的边界是：如果“自动加好友”指的是用户扫码、点击获客链接或点击小程序按钮之后，企业成员侧自动通过验证，那么官方能力可以覆盖一部分，skip_verify、渠道 state、添加客户事件、欢迎语接口都能参与编排。如果“自动加好友”指企业后台拿手机号、openid、unionid 或业务系统里的用户 ID，直接向对方发起好友申请，官方客户联系 API 没有这个能力。 “主动拉群”也类似。官方 API 可以创建客户群“加入群聊”的二维码或小程序按钮，用户扫码或点击后进入客户群；也可以在新客户欢迎语里发送入群入口。但官方文档没有提供服务端接口，让企业把某个 external_userid 静默拉进客户群。客户群群发也不是直发接口，而是创建群发任务，仍然需要成员确认后才会发送。 所以，合规可落地的方案不是“后台替用户完成好友和入群动作”，而是“用户主动触发建联，系统自动识别渠道、分配跟进人、发送欢迎语、发放入群入口，并通过回调...
数据库 Resharding 的在线切换与回滚
Resharding 是分库分表架构绕不过去的难题。系统上线时用 uid % 2 把数据分到两个库，跑了两年发现容量不够，要扩成四个库——uid % 4。这个 % 号一变，大约 75% 的数据需要重新搬家。搬数据本身不难，难的是三件事同时做到：在线搬、搬完瞬间切、切坏了能回滚。 下面从最朴素的双写到 Vitess 的 VReplication，逐一拆解业界主流的 resharding 在线切换方案。核心问题只有三个：数据怎么不丢，流量怎么瞬间切，故障怎么秒级回。 问题的本质：hash mod 变化引发的数据海啸 hash 取模是最常见的分片路由策略。uid % N 的 N 一旦改变，绝大部分数据的归属分片都会变。 以 2 库扩 4 库为例：原先 uid % 2 = 0 的数据全在 A 库，扩容后 uid % 4 把这批数据拆成了 uid % 4 = 0（留 A 库）和 uid % 4 = 2（搬到新 C 库）。B 库的情况类似，一半数据要搬去新 D 库。 12345678910111213扩容前（uid % 2） 扩容后（uid % 4）┌─────────┐ ...
