置身圈内：把工作中的摩擦交给 Agent
引子
开篇先和大家同步一个进展：
三个月前，我在《置身圈内：Loop Engineering 踩坑实录》里写过，我和 Z 同学每天围绕 Code Review 打乒乓球：发 PR、催 review、收到意见、修改，再通知对方。当时我半开玩笑地说，或许有一天，这些对话会由我们各自的 Agent 接手。
现在，这个玩笑正在变成真实的工作流：我的本地 loop Agent 完成验证、提交，在 GitLab 上发起 PR，再通过钉钉提醒 Z 同学；而他的 Agent 先做 Code Review，供他判断。批准或否决仍由人作出，结果再作为信号流转回来。GitLab 上两个 Agent 相互评论，钉钉上也是互相提醒。我和 Z 像是从乒乓球运动员往后退了一步，变成了教练员。
Agent 开发、review、摇人一把抓，似乎离全自动开发只是一步之遥，10x 效率提升指日可待？Dreams come true？
No！这三个月，我的工作重心从直接参与软件生产交付，逐渐移向售后服务和运行维护。但要关心的工程反而更多了：上游的前后端和计算引擎，下游的运维、技术支持 Agent，常常同时有几条线在跑。我也越来越确定，阻碍工作流动的未必是最难的技术问题，更多时候是散落在工具、任务与人之间的小摩擦。
毕竟，Coding 只是传统 SDLC 中的一个小小环节。如果不对整体流程重构，软件功能从需求收集到迭代上线，势必还是会经历多重环节的沟通、确认、交接。这里面的口径对齐、沟通损耗、信号衰减，都会让生产力打折。另外从人的层面看，研发团队、产品团队、运维团队等也不可避免地会承接各类信息转移的工作（例如客户答疑、架构培训、供应商资质审核等等），这会进一步分散人宝贵的注意力。
上一篇文章更多讨论如何设计工程回路。这次我想从这个小变化继续往下看：怎样减少个人使用工具的阻力，以及团队交接信息的阻力。但考虑到观远在这个话题上也是在探索中，本文先不展开宏大的组织命题，只谈已经上手实践的“术”与“器”：怎样打磨工具，以及尽量给人的注意力减负。至于道法层面的方法论，等我们真正跑通了会再和大家分享。
让工具适合自己
常话说得好，磨刀不误砍柴工，更何况现在这把刀还能自我进化。
在 2026 年，不知道还有多少程序员还在使用 Cursor。曾经通过智能补齐等功能迅速占领 IDE 市场的这个下一代编程利器，似乎已经让位于 Codex、Claude Code 一类的 Coding Agent。
但是对于我个人来说，我已经习惯了 Cursor（或者说 VS Code）的字体搭配。相比之下，Codex 默认的白色背景以及偏小的字体，对我这样一枚“中登”程序员很不友好，会时常让我本就干涩的双眼雪上加霜，经常无语泪先流。
于是我让 Codex 帮我研究 Cursor 的观感，再调整自己的字体与深色配色。
现在我的 Codex 代码字体设为 16 号，界面颜色也更接近我熟悉的风格，简直就是复刻了 Cursor 一样。
这件小事提醒我：Harness 不只包含提示词、Skill 和测试，也包含人每天盯着它工作的界面。一个能持续使用的系统，首先应该让使用者看得清、待得住。
更好地管理你的并发任务
再举一个打磨工具的例子。
Coding Agent 火起来之后，一时之间，长程任务的持续时间和并发度，变成了评价一个 Harness 套件使用效率的核心指标。我有段时间 6、7 个任务并行跑，需要不停地在各个 Agent 会话间“反复横跳”，忙得不亦乐乎。但我一直对 Codex 的项目组织和任务会话管理不太满意。主要是：
- 任务级别的检索比较弱，似乎只能通过关键字匹配来命中会话标题，而不是针对内容检索。为了解决这个问题，我专门让 Codex 自己写了一个 Skill，来模糊搜索其背后的 SQLite 数据库，当然 Token 消耗也是很可观的。
- 状态管理也比较弱。哪些是正在运行的会话，哪些是最近完成的会话，要通过多次点击、切换任务模式才能获得。任务一多，Codex 的项目和任务列表对我来说就不够直观。我试过桌面宠物，甚至把桌宠的头像做成了喜欢的旗木卡卡西；它很有趣，但在不大的显示器上会占一角，点击时也可能挡住别的内容，其实用起来很不趁手。
于是提需求给 Codex。
最后经历了一轮讨论后，从易用性、可维护性考虑，Codex 决定做一个脱离了自己的伴生应用。
它只做几件事：把运行中的任务放在上面，保留最近 20 个已完成任务；按任务名、项目或路径搜索；点一下就跳回 Codex 里的那条任务。它定时刷新，不要求我守着一堆窗口。
我没有去看它的实现。一方面它是 Codex 用 Swift 实现的，而我的技能栈还停滞在中括号编程的时代（懂的都懂 -_-）；另一方面，在 Vibe Coding 时代，对于这些自用的内部工具，似乎也没有必要关注实现的细节，放手交给 Agent 吧☺。
这个小工具没有试图重新发明项目管理。它解决的是“我现在该回到哪条线”这个高频问题。Agent 处理任务，Agent 也能为管理这些任务造一件合手的器物。
把信息搬运交给“虚拟员工”
除了人与工具间的摩擦，另一类摩擦发生在人与人之间。客户会问产品能力，团队之间会问安全、产研流程或合同技术条款。很多问题并非需要我从头思考，只是信息原本在我的脑袋或文档里，提问者此刻找不到。
面向客户的产品问答机器人已经上线，能在一线回答不少产品问题。内部我原本也希望同事直接找 Agent，但大家还是习惯在钉钉群里 @ 人。既然如此，不妨先给被提问的人配个秘书：Codex 的定时任务从已有对话中识别问题，再借助 Skill 和知识库找依据、起草回复。
合同技术审核是正在试跑的一条线。最近一次，任务从群聊里识别出 4 条请求，生成了待我审阅的回复草稿，没有自动向群里发消息。其中有条问题只给了合同截图，看不清条款原文；Codex 没替我作出判断，而是要求先补原文，再确认技术上能否承诺。目前我们还没有让它直接在群里回复合同问题的案例。
现在谈不上让 Agent 代替谁。它先替我盯住散在对话里的问题，把能找到的材料放到眼前；涉及合同承诺的判断，还是由我来做。测试打包等其他“人找人”的场景，我们也想沿着这个方向试试。
另外，下班后，我也用 Codex 的定时任务守护微信读书。每天固定时间它检查当天阅读时长：达到 6 分钟就安静结束，没达到就进入提醒流程。例如，9 月 28 日它查到 3 分 57 秒，29 日查到 3 分 59 秒，两次都触发了提醒。“今晚读够没有”终于不用一直占着脑子。
小结
这些尝试还在变化，谈不上终局。
放在“道、法、术、器”里看，本文主要记录“术”与“器”：怎样把评审、问答和提醒安排成可执行的动作，再用界面、任务面板、Skill 和定时任务把动作接起来。至于 Agent 如何与人和组织相处、AI 原生组织会是什么形态，还需要更多实践。目前我们也在关注 Jev 和 DeepSeek Harness 等新尝试；等有了自己的验证，再来和大家同步。
眼下更实际的是，把催 Review、翻聊天记录、找回正在进行的任务、惦记阅读时长这些低水平、重复、持续消耗精力的事务，逐步托管给 Agent。它能处理的就让它处理；需要判断、承担责任的地方，让它带着材料回到人面前。省下来的注意力，不是为了往一天里塞进更多任务，而是还给大脑，去思考更重要的事、做出更准确的决策。
嗯，我仍在圈内。
只是这个圈里，多了几位能接球的 Agent。
写在最后
最后，照例推荐两本书。最近读《软件设计的哲学》，这本书讲的是如何理解软件的复杂度，如何构建功能齐备、性能达标、方便维护的软件系统。 读完我会追问自己：在 Vibe Coding 时代，代码产出更快了，我们是否还在认真控制复杂度？工具可以替我实现逻辑，但设计上的取舍不能随手外包。
《搞定Ⅰ：无压工作的艺术》（Getting Things Done）给我的另一个提醒是：把脑子从琐事里解放出来。GTD 把待办从脑中移到可信的外部系统，再分清哪些马上做、哪些留待以后、哪些可以委托。我在想，能否借助 Agent 做一套自己的「GTD Agent」：收集和分类由它帮忙，可执行的事务交给它，涉及判断的仍回到人手里？这还只是一个设想。
