守株阁

内部控制面边界 把 AI coding agent 理解成“会写代码的模型”，很容易低估真正的工程难点。模型只是运行时里的一个决策器；让它长时间稳定地改代码、跑命令、处理错误、收敛到可验证结果，靠的是更外层的控制面。 这层控制面通常由五件东西组成： Agent loop：一次任务怎样从观察、计划、行动、再观察，走到验证和停止。 Hook：在关键生命周期点插入确定性规则、审计、阻断、上下文补充和通知。 Plugin / Skill / MCP server：把工具、上下文、工作流、文档、浏览器、团队协作能力装进运行时。 Sandbox / Permission：决定哪些动作可以自动执行，哪些必须询问，哪些直接拦截。 Trace：把循环、hook 决策、工具调用、错误、重试和验证证据留下来，供复盘和调试。 协议层和运行时层要先分清。MCP、A2A、AG-UI 这类协议主要回答“对外怎么互通”：客户端、服务器、工具、资源、提示词、传输、能力协商和界面事件如何标准化。Hook、loop、plugin、sandbox 和 trace 回答的是“内部怎么行动”：一个 agent 何时调用...

两篇文章的最终定位 这组文章按一条边界切开：A 文讲外部接口和生态分层，B 文讲内部控制面。A 文回答“Agent 如何和工具、数据、其他 Agent、用户界面、观测评估系统相连”；B 文回答“一个 coding agent 在本机如何循环、拦截、授权、扩展和复盘”。 内容 放在 A 文 放在 B 文 MCP / A2A / AG-UI 作为三类互操作协议，分别解释工具上下文、Agent 间协作、Agent 与 UI 同步 只讨论它们进入 runtime 后如何变成 tool、server、permission、trace OpenAI Agents SDK、LangGraph、Google ADK、CrewAI、AutoGen/AG2、LlamaIndex、Semantic Kernel、Pydantic AI、Mastra、Strands Agents 作为 agent runtime / framework / platform 的生态层，说明它们和协议层的关系 只保留和 loop、hook、plugin、sandbox、trace 强相关的运行时判断 ...

AI Coding 工具的讨论很容易滑向品牌比较：哪个补全更快，哪个模型更强，哪个界面更顺手，哪个 Agent 更会自己修错。 这种比较有用，但不够。真正影响团队落地效果的不是单个工具的功能清单，而是三个更底层的问题：产品形态默认鼓励什么工作流，任务方法论如何控制风险，Harness 能不能把验证、状态、权限和恢复托住。 把这三层拆开后，AI Coding 工具的差异会清楚很多。IDE、CLI、Spec 工作流、云端 Agent 并不是互相替代的银弹，它们只是把人的注意力放在不同位置。 先看产品形态，不先看品牌 AI Coding 工具大致可以抽象成四类形态。 形态 默认入口 强项 代价 IDE 辅助型 当前文件、光标、选区 低摩擦、适合局部修改 容易停留在补全和问答 CLI Agent 型 任务描述、仓库、命令行 端到端闭环、天然适合自动验证 需要更强的权限和环境治理 Spec-first 型 需求、设计、任务清单 适合 Feature 级需求和长任务 小修小补显得偏重 混合型 IDE 协同加 Agent 执行 能在编辑体验和任务闭环之间切换 产品边...

AI Coding 的早期问题通常是模型能力不足。补全不稳定、上下文短、工具调用弱，开发者只能把模型当作更快的搜索框或更会改局部代码的副驾。 这类问题正在退到后面。模型输出的边际价值一旦稳定超过 token 成本，真正稀缺的东西就变成了人的在线注意力：谁来持续拆任务、喂上下文、看日志、判断结果、处理失败、决定哪些改动能进入主干。 “睡后 Token”描述的不是熬夜让模型跑得久一点，而是一种工程分工的变化：人提前定义目标、边界和验收口，Agent 在人离线时持续生成候选结果，等人回来时只处理已经被筛过一轮的判断对象。 瓶颈从模型转到人 过去讨论 AI Coding，经常把问题压成一句话：模型够不够聪明。 这个问题仍然重要，但它不再解释全部差异。两个团队使用同等能力的模型，一个只能做单文件补全，另一个可以稳定跑完多仓库修改、自动验证、失败回收和审查流转，差距主要不在模型本身，而在模型外面那层工程系统。 AI Coding 的生产率瓶颈大致经历了几个阶段。 阶段 典型形态 主要瓶颈 工程含义 IDE 辅助驾驶 补全、局部改写、问答 人不动，token 就停 模型像更锋利...

分页通常是一个很安静的接口参数：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 像控制规格...

结论先放在前面 截至 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 倍。 这些数字说明的事情很简单：很多团队在抱怨"模型不够...