守株阁

两篇文章的最终定位 这组文章按一条边界切开：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...

分页通常是一个很安静的接口参数：page_no、page_size，或者 limit、offset。数据量小时，它几乎没有存在感；等列表长到几十万、几百万行之后，同一条 SQL 只是把 OFFSET 往后挪了一点，延迟却会突然变得难看。 问题不在“翻页”这个动作本身，而在系统被要求从一个有序结果集里跳过很长的前缀。RDBMS、Elasticsearch、Hive 的表现各不相同，底层代价却很接近：先把前面的候选算出来，再把它们丢掉。 这也是深翻页最容易被误解的地方。它不只是 SQL 写法问题，还牵涉访问路径、排序稳定性、产品交互，以及底层系统是否需要跨节点合并结果。一个可用的分页方案，往往先从产品语义开始，而不是从 LIMIT 990000, 1000 开始。 深翻页的成本来自“计算前缀再丢弃前缀”。优化要么把前缀变窄，要么把“第 N 页”改成“从某个锚点继续”，要么提前把结果集物化成可跳转目录。 一个大表实验 有一个很典型的大表实验：表里大约 1000 万行，按 status 过滤后命中约 100 万行。测试环境是本地硬盘，慢查询阈值按 100ms 估算。几条查询的结果很...

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（persistent agent / durable agent）指的是另一类系统：它承接的工作生命周期长于单次模型调用、长于单个上下文窗口、长于单个进程，甚至长于发起它的那台设备。 一个夜间跑依赖升级的 agent、一个跨三天迁移代码库的 agent、一个每周整理 issue 的 agent，都属于这一类。它们的共同点是：任务的时间尺度和会话的时间尺度脱钩了。这篇文章给「持久」下一个可操作的定义，并整理支撑它的三根支柱。 本文与已有文章的边界 已有文章 主要讨论 与本文的关系 ReAct：推理与行动交织的 Agent 循环原型 单条轨迹内的推理-行动循环 ReAct 是内环，本文讨论内环之外怎么让任务活下去 Agent 全景指南 Agent 范式演化与高可用 提供范式背景，本文聚焦持久性这一个维度 Goal 模式深度研究 完成谓词、循环停止条件 完成谓词决定持久任务什么时候可以死 Harness Engineering：长程 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 包在循环外面，本文讲循环本身从哪来 环境可供性：智能的一半是取到...

结论先放在前面 截至 2026-06-06，企业微信官方 API 不能完整实现“企业后台自动把商铺业主和普通用户加为好友，然后主动把他们拉进群”这件事。 一个容易混淆的边界是：如果“自动加好友”指的是用户扫码、点击获客链接或点击小程序按钮之后，企业成员侧自动通过验证，那么官方能力可以覆盖一部分，skip_verify、渠道 state、添加客户事件、欢迎语接口都能参与编排。如果“自动加好友”指企业后台拿手机号、openid、unionid 或业务系统里的用户 ID，直接向对方发起好友申请，官方客户联系 API 没有这个能力。 “主动拉群”也类似。官方 API 可以创建客户群“加入群聊”的二维码或小程序按钮，用户扫码或点击后进入客户群；也可以在新客户欢迎语里发送入群入口。但官方文档没有提供服务端接口，让企业把某个 external_userid 静默拉进客户群。客户群群发也不是直发接口，而是创建群发任务，仍然需要成员确认后才会发送。 所以，合规可落地的方案不是“后台替用户完成好友和入群动作”，而是“用户主动触发建联，系统自动识别渠道、分配跟进人、发送欢迎语、发放入群入口，并通过回调...

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）┌─────────┐ ...

Anthropic 在 claude-quickstarts 仓库中放了一个 autonomous-coding 示例项目。整个项目只有 8 个 Python 文件、约 500 行代码、一条 pip 依赖（claude-code-sdk>=0.0.25），却能驱动 Claude 在多个 session 之间持续工作数小时，从零构建一个带 200 个测试用例的完整 Web 应用。 这个项目的价值不在于它有多复杂，恰恰在于它有多简单。它是 Anthropic 对"长程自主编码的最小可行 harness"的官方回答，每一个设计决策都值得拆开看。 项目全景 12345678910111213autonomous-coding/├── prompts/│ ├── app_spec.txt # 应用规格说明书│ ├── initializer_prompt.md # 初始化 Agent 的 prompt│ └── coding_prompt.md # 编码 Agent 的 prompt├── autonomous_ag...

2026 年 5 月，CMU、Yale、JHU、Virginia Tech、Amazon 等九家机构联合发布了一篇 71 页的综述论文《Agent Harness Engineering: A Survey》。19 位作者对 170 余个开源 Agent Harness 项目做了系统编码，提出了 ETCLOVG 七层分类框架，并给出了一个在业界讨论中反复出现但缺少严格证据支撑的判断：制约 Agent 可靠性的瓶颈不在模型，而在模型外面那层工程系统。 Harness 改一改，性能翻几倍 论文引用了一组对比实验：把 GPT-5.2-Codex 固定不动，只修改 Harness 层——重写系统提示词、加入中间件上下文注入、增设自验证钩子——Terminal-Bench 2.0 得分从 52.8% 升到 66.5%。进一步用自动化 Meta-Harness 优化器调参，分数到了 76.4%，超过人工调优的最好成绩。 另一组实验更激进：仅修改 edit-tool 的格式协议和工具调用规范，编码基准测试的改善幅度达到 10 倍。 这些数字说明的事情很简单：很多团队在抱怨"模型不够...

一个项目目标听起来不复杂：把一个已经在线上跑的「客资诊断」agent 系统，用新的技术栈复刻一遍。原系统能根据一个业务 ID 把整条链路的状态查清楚：数据有没有入库、短信发没发、有没有回访，然后给一线同学一份诊断报告。 真正的难度集中在一处：新系统接的工具语义接近、定位接近，但签名不保证一致。项目里专门记失败的那个文件 failuremode.md，最终攒了 47 个不同的 FM 编号。这不是 bug 列表，而是「同一个错误以后还会换个皮再犯」的结构性失败模式。下面把它们摊开看：这些坑的形状高度相似，认出形状比记住每一个坑更有用。 为公开发布，所有内部平台名、数据集名、工号、手机号、文档 ID 均已脱敏，换成功能描述。技术含义不变。 先说那个数字 文档头、README、架构说明里都白纸黑字写着「32 FM-* 失败模式库」。实际 grep 一下： 12grep -oE "FM-[A-Z0-9-]+" docs/failuremode.md | sort -u | wc -l# 47 43 个独立的 ## 段落，加上某个大类底下挂的 4 个子类型，一共 47 个...