上周我让一个 Coding Agent 给一个 Web 应用实现登录功能。三轮迭代之后，它汇报：「完成了，所有测试通过。」
我打开浏览器一看：登录按钮不见了。
我把截图丢回去，它看了一眼，回复：「抱歉，上一轮我把按钮组件误删了。」
有意思的不是 Agent 会犯错——犯错很正常。有意思的是： 它直到看见那张截图，才知道自己犯了错。 那三轮迭代里，它有编译反馈，有测试报告，但它没有任何办法知道最终页面长什么样。它的「世界」是残缺的。
这件事让我更确认了一个琢磨了很久的判断：
[Read More]对于 Coding Agent，最重要的基础设施不是更聪明的模型，不是 Benchmark，而是端到端（E2E）Test Harness。
昨晚十一点半，我盯着自己那个钉钉数字员工项目里的一段代码发呆。
那是 core 模块里的轮询逻辑——每隔 3 秒去 serve 端拉一次会话状态，判断任务是否完成、是否超时、是否需要 abort。旁边是 session 管理：维护一个内存里的 Map，记录每个会话的生命周期、重试计数、上下文快照。再往下是 abort 清理：当用户取消任务时，要优雅地终止正在执行的工具调用、回收资源、把中间状态写回。
加起来大概 200 行。写得挺漂亮，有状态机、有超时退避、有异常兜底。我三个月前写它的时候，serve 端还没有原生的会话生命周期管理，没有 SSE 事件流推送，没有内置的 abort 语义。这 200 行是当时唯一的选择。
但昨晚我突然意识到： 这些代码的保质期，可能只剩一年。
不是因为它们写错了，而是因为它们正在被模型和运行时从两端同时吞噬。
[Read More]上周一个 FDE 跟我说：「我在客户现场搭一个群聊数字员工，从建账号到调通花了两天。其中一天半在处理断线重连、图片下载、消息去重这些脏活。」
我给他看了 dingtalk-opencode-tag：下载 opencode + 装 dws + 钉钉扫码授权，三步上线。跑在免费模型上，起步成本为零。
他试了一下，十分钟就通了。然后说了一句让我印象很深的话：「这不只是一个脚手架，这是一种交付范式。」
他说得对。这个项目的意义不在于它做了什么——文本对话、图片识别、文件解读，这些功能谁都能写。意义在于它 把生产环境的脏活封装成了可复制的 Harness，让数字员工的上线门槛从「一周的工程工作」降低到「三分钟的配置」。
[Read More]
从只有大模型到完备 Harness：7 个组件缺一不可
上周我让 Agent 帮我写了一篇博客。
它从我的 wiki 里读了 5 篇历史文章做去重分析，生成初稿后自己跑了一轮对抗性评审打了 18 分，然后用 Gemini 生了一张配图、resize 到 1360px 以下、压缩成 948KB 的 PNG，再跑了一遍中文排版修复，最后 commit 推到 GitHub，等 CI 构建完成后自己验证了上线 URL。
整个过程我做了三件事：选了一个标题方向，补了两处内容，说了三次「发布」。
这套流水线跑了 4 篇博客（#290 到 #293），每篇都是这个流程。它不是 demo，是真实的生产管线。
但我回头看这套东西的时候，发现一个问题： 我搭出来的不是一个 Agent，是一个 Harness。
[Read More]上周三晚上，我躺在沙发上刷手机。钉钉里我那个写代码的机器人卡在一个 question 上——它问我要发到哪个群，我没看见。第二天早上才发现，会话已经卡死了一整夜。
我没起身，随手在钉钉单聊里给它发了句：「给 event-watcher 加个超时自动取消，60 秒没答就 reject。」
十分钟后，机器人改完代码、跑完语法检查、重启了它自己、把改动 commit 推到了 GitHub。我在钉钉里收到一条回执：「✅ 已重启，能力：question 超时自动取消。」
它刚刚修好的，正是那个卡了它一整夜的 Bug。整个过程我没打开电脑。 机器人在钉钉上开发了它自己。
昨晚我用 OpenCode 在钉钉上写一个会议通知 Agent。需求很简单：查日历找到明天的会议，给参会人发一条钉钉消息。
OpenCode 读完了 DWS CLI 的 help 文档，开始生成调用代码。它要发消息，看到了三个命令：dws chat message send、dws chat message send-by-bot、dws chat message send-by-webhook。它选了 send，传了 --group 和 --text，没传 --title。
返回了一个错误：「发群服务窗会话消息失败」。
OpenCode 懵了。我也懵了。什么「服务窗」？我在发群消息，跟服务窗有什么关系？
后来我翻了 dws chat message send --help，在最底下发现了一行小字：
--title是消息标题，群聊与单聊都必填（API 强制要求；缺失时返回误导性的「发群服务窗会话消息失败」）。
平台团队知道这个错误信息是误导性的，他们选择在 help 文档里标注「误导性」，而不是修复 API 的返回。
但这还没完。OpenCode 继续工作，又遇到了第二个问题：send 命令有三个互斥的目标参数——--group（群聊）、--user（userId）、--open-dingtalk-id（openDingTalkId）。help 文档说「三者只能选其一」，但没有解释什么时候该用哪个。userId 和 openDingTalkId 的区别是什么？Agent 无从推理——它只能猜，猜错了再换。
这整个过程花了十几分钟。但这十几分钟本来不应该存在。
这不是假设场景，这是 DWS 今天的真实状态。
4 月底，OpenAI 发布了 Codex CLI 0.128.0。更新日志里藏着一句话：「Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls.」几乎同一时间，Claude Code 也上线了 /goal 指令。Greg Brockman 在推特上写了一句：「codex now has a built-in Ralph loop++.」
大多数人把这条更新当作又一个 feature flag 滑过去了。但如果你仔细拆解 /goal 的设计，会发现它代表的不是「又一个功能」，而是 AI Agent 工程的一次范式跃迁。
知识管理有四个值得做的企业场景，其中「企业 SOP / 最佳实践沉淀」看起来最不起眼——知识静态、更新慢、容易退化成高级搜索、用户日活偏弱。
但如果你换一个角度看，SOP 沉淀的真正价值不是「把经验存起来」，而是 把经验变成可执行的系统行为。
这篇文章用一个完整案例来说明：一位 Windows 用户打开悟空发起任务，悟空报错「任务执行环境准备失败」，到 AI 定位根因、修复代码、验证、发布，全程 4 小时。每个环节 AI 做什么、人做什么、知识如何在这个过程中自然沉淀。
[Read More]Netflix 的「Context, not Control」曾经是最有影响力的管理理念之一。
它的核心假设很简单：给聪明人足够的上下文，他们会用你没想到的方式达成目标。你不需要控制过程，只需要提供信息、方向、约束。人的判断力、创造力、直觉——这些是 context 之外的东西，也是 Control 管不到的东西。
但这个理念套到 Agent 上，假设崩塌了。
HashiCorp 的 Mitchell 把自己的 AI 使用历程分成六个阶段。他不是那种用了就觉得好的人，每个阶段都带着怀疑和验证。六步走完后，他得出了一个反直觉的结论：最痛苦、看起来最「无用」的第二步，恰恰是后续一切复利的起点。
大多数人从第一步直接跳到第四步 —— 觉得 AI 好用就开始委托任务。Mitchell 却在第二步花了大量时间做冗余工作：已经手动完成的事，再让 Agent 做一遍。原文说「I literally did the work twice」。目的不是省时间，是建立对 Agent 能力边界的真实认知。
正是这个阶段的「无用功」，让后续每一步都产生了指数级的复利效应。
[Read More]