Agent-Reach 实战：AI Agent 触达能力设计与 CLI 工程实践
2026/10/8 0:07:41
DevDay 之后，开发者对话里常出现一种假对立：云端常驻 Dot负责跟进与长跑，本地 IDE Agent负责改仓与测试。产品名会变，分工问题不会变——任务在哪里闭环，写权限默认给谁。
本文是观点文：不复述发布会清单，不编造价目与基准分数，只给可执行的「押注」框架。与 10-01 快报、10-05 Sol 定位文互补：那边讲启示与换通路，这边讲默认策略。
摘要
- 分化真实：常驻跟进 vs 仓库真相源，是两个场。
- 假对立：不是永远只押一边，而是写权限与验收位置的选择。
- 默认建议：调研可云端；改仓 + 跑测默认本地 IDE Agent。
- 云端产物：备忘/草稿入库，不直合并受保护分支。
- 纪律：分通路记账；能力以官方为准。
结论：押工作流与权限默认值，不押单一 Logo。
结论卡
| 问题 | 更稳的答案 |
|---|---|
| 该押 Dot 吗？ | 押「跨会话跟进/调研」场景，不押代替 Git |
| 该押本地 Agent 吗？ | 押「改仓+测试+Rules/MCP」主场 |
| 能否只用一边？ | 个人可以；团队建议双轨+闸门 |
| 如何避免漂？ | 写默认权限约定，而不是追热搜 |
| 价目？ | 只看官方，本文不给数字 |
两个场，不是两个宗教
云端常驻 Dot（公开叙事下的工程直觉）：跨会话记忆与跟进、调研与长跑整理、与 Space 等共场协作。强项是「事情还在线上被惦记」；弱项是——一旦要改你的私有仓库、跑你的测试、遵守你的 glob Rules，它不是本地文件系统的真相源。
本地 IDE Agent：文件与测试是第一真相；Rules、MCP、多根工作区、终端红绿循环都在旁边。强项是工程闭环；弱项是——跨多日、跨工具的「项目经理式跟进」往往要你自己用任务卡与会话摘要补齐。
把二者骂成「谁取代谁」，通常是营销话术在脑内演戏。工程上更常见的是：云端产出备忘，本地落地补丁。
押哪边：先问闭环
- 任务：必须改当前仓库并看测试红绿？→ 本地。纯调研/纪要/方案对比？→ 云端常驻跟进很合适。
- 权限：涉及内网、私有 MCP、本机密钥？→ 本地闸门。需要广域检索且官方通路允许？→ 云端可参与只读。
- 闭环：谁点合并、谁跑 CI？若答案是「人 + 本地 Git」，就不要让云端智能体拥有默认写权想象。
- 组合：双轨——云端整理「问题清单/候选方案」，本地 Agent 执行「最小 diff + 测试」；不可逆操作只留人工。
经验口诀：闭环在仓库 → 本地；闭环在调研 → 云端；写生产仓 → 永远偏保守。
开发者该押什么（可写进团队约定）
- 默认：调研可云端，写仓只本地。
- 云端产物以 Markdown 备忘或 PR 草稿形式入库，不直推
main。 - 本地 Agent配齐精简 Always Rules、域 glob、MCP 最小集与测试闸。
- 分通路记账，避免「感觉哪边便宜」——固定税（前缀/工具/脏历史）两边都会收。
- 产品能力与价目以官方为准；Demo 权限当不得默认生产权限。
这五项才是「押注」：押的是习惯与闸门，不是押某一季发布会的主角名。
和创作之星、系列文的关系
观点若只停在站队，明天就过期。把它落成：一篇决策表 + 仓库里的 CONTRIBUTING 片段 + 系列实战文互链，才变成长期权重。九月创作之星收官在即，用「默认权限」这类可复用方法文，比追每一个新名词更稳——后文 10-07 会专谈系列文策略。
为什么「押边」会被营销话术带跑
发布会叙事喜欢单主角：某季是常驻智能体，某季是效率模型，某季是协作空间。开发者若把「押边」理解成「All-in 一个产品名」，会在下个季度重新站队，团队规范来不及沉淀。
工程上的押边应当写成默认策略：
- 默认只读调研通路；
- 默认写仓通路；
- 默认验收命令位置；
- 默认禁止的自动操作。
产品名可以换，这四行尽量少换。这也是为什么本文强调「押工作流与权限默认值」。
双轨协作的一天长什么样
上午：在云端常驻助手里整理「问题清单 / 候选方案 / 开放问题」，导出为仓库内docs/notes/YYYY-MM-DD.md。
下午：在本地 IDE Agent 按委派卡改代码，跑测试，出最小 diff。
傍晚：人工审 diff 与笔记是否一致，开 PR。
夜间：若需要跟进调研，把开放问题丢回云端助手，但不授权写仓。
这种一天并不浪漫，但很少出现「智能体昨天改过、今天找不到提交」的事故。
个人开发者与小团队的差异
个人可以极端：全程本地，或全程云端草稿再手搓。小团队则必须把默认策略写进 CONTRIBUTING，否则每人一套「我以为的安全」。尤其实习生与轮岗同学，会把 Demo 里看到的高权限当成日常。
建议在仓库加一页docs/agent-defaults.md，三十二行以内，链到本系列相关文。观点文负责「为什么」，仓库页负责「我们选哪边」。
不要用基准分代替权限设计
公开基准与演示视频解决的是「能不能」。权限设计解决的是「该不该自动做」。DevDay 安全线相关讨论已经提示：授权边界比分更重要（见 10-01 观点）。把这句话落到 Dot vs IDE 选择上，就是——云端再强，也不自动获得你的写仓默认权。
边界声明
- Dots / Space / 相关能力以 OpenAI 官方说明为准；本文不声称某一功能的未公开细节。
- Cursor 等本地 Agent 的模式命名以产品当前 UI 为准。
- 不编造任何价格；区域与套餐可用性各自查询。
收束
赛道在分化，开发者的最优解很少是「All-in 一边」。更像是：让云端常驻智能体擅长它的跟进与整理，让本地 IDE Agent 守住仓库与测试，用人工闸门焊死写权限。押边，就是押你默认信任谁改代码。把这句话写进团队公约，比在评论区站队有用得多。