Signal #18：Coding Agent，从 IDE 走进研发系统

过去我们讨论 AI Coding，很多时候默认有一个前提：**先打开一个工具，再让 Agent 做事。**这个工具可能是 IDE，也可能是 CLI、云端任务界面，或者浏览器里的 Agent 面板。开发者描述需求，Agent 读取仓库，修改代码，跑测试，最后生成一个 diff 或 PR。这条路径仍然重要，也是大多数人最熟悉的 AI Coding 使用方式。

但本周几个产品更新放在一起看，一个更值得记录的变化开始变清楚：**Agent 接任务的入口，正在从工具界面转向真实研发系统。**未来不一定是人先打开 Agent，再把需求复制进去；更可能是需求单、文档讨论、Slack 线程、PR 评论、Review 结果这些研发对象，本身就可以把任务派给 Agent。

这件事比“Agent 又多接入了一个工具”更重要。它意味着 Coding Agent 正在从“开发者手里的工具”，变成“研发系统里的执行者”。

**真实研发工作不是从 IDE 开始的。**需求先出现在需求单里，问题先出现在 Slack 讨论里，改动理由可能藏在 Notion 文档或 Confluence 页面里，bug 也可能是在 PR Review 里被指出来的。过去这些内容更多是“人看的上下文”，人看完之后，再整理成任务交给开发者或 Agent。现在，这个动作开始前移。

**GitHub Copilot for Jira 正式 GA 后，Jira issue 不只是记录需求和进度的地方，也可以成为 coding agent 的工作入口。**GitHub 提到，用户可以在 Jira workspace 内启动 Copilot cloud agent session，并基于 work item 的标题、描述、标签、评论、自定义字段等上下文打开 PR。需求单不再只是“任务说明”，而开始变成“任务控制台”。《GitHub Copilot for Jira is now generally available》

**Cursor 和 Notion 的集成也是同一类信号。**Notion 不是代码工具，它是文档、项目、知识库和协作现场；但 Cursor 在案例里写到，Notion thread 会映射成一个 Cursor agent，thread 里的每条 message 会变成一次 agent run，并可以带上 repo、model、MCP servers 和 automatic PR creation。产品文档和讨论线程，正在变成代码任务的入口。《How Notion used the Cursor SDK to embed coding agents》

**Anthropic 的 Claude Tag 则把这个入口放到了 Slack。**Claude 可以加入被授权的 Slack 频道，连接指定工具、数据甚至代码库；团队成员可以在频道里 @Claude 委托任务，Claude 会在 thread 中拆解、执行并返回结果。Slack thread 过去是讨论的地方，现在开始变成 Agent 读上下文、接任务、给反馈的地方。《Introducing Claude Tag》

这些更新单独看，都是产品集成；放在一起看，方向很清楚：Agent 接任务的地方，正在从 IDE 和 Agent 工具，移动到需求单、文档、线程、PR 和 Review 这些真实研发对象里。

**这里说的研发对象，不是一个新概念。**它指的是需求单、PR、Review 评论、文档、Slack thread、测试报告、安全扫描结果这些日常研发协作里的具体对象。它们本来承载的是人类协作信息：谁提出了问题，为什么要做，讨论过哪些方案，限制条件是什么，谁需要确认，最后如何验收。

过去 Agent 更擅长处理代码对象，比如文件、函数、diff、测试、命令行输出。**但一个研发任务真正需要理解的东西，往往在代码之外：**为什么要改，哪些方案已经被否过，这个改动影响哪个用户路径，验收标准是什么，是否有设计规范、交互约束、安全边界和性能目标。

**这也是 Vercel 那篇 product-design skill 值得看的原因。**Vercel 把已经被接受的产品决策像代码一样放进仓库，经过 review，并提供给每个 Agent 使用；这个 product-design 系统由 agent skill、自动化 linters，以及从 Slack、Figma、GitHub 收集证据并准备 guideline 更新的 review loop 组成。关键不是“给 Agent 写一段提示词”，而是把产品判断、设计规则和历史决策整理成 Agent 可读取、可触发、可验证、可持续更新的工程资产。《Teaching agents product design at Vercel》

所以，当 Agent 从 IDE 走进研发系统，问题就不再只是它能不能读懂代码、生成实现、跑通测试；还包括它能不能读懂任务、理解讨论、识别哪些上下文有用，知道一条 PR 评论是在要求修改、质疑方案，还是提醒风险，并且在产品约束、安全要求和工程规范之间做出可审查的选择。

**把 Agent 放进 Jira、Notion 或 Slack，并不等于它就能稳定完成任务。**人和人之间派活，很多时候靠默契：需求写得不完整，研发可以去问产品；评论只写“这里不太对”，作者大概能猜到 reviewer 在说什么；Slack thread 很散，但团队成员知道前因后果。Agent 没有这种组织默契，它需要更明确的任务包。

**一个适合 Agent 执行的任务，至少要包含几类信息：**任务目标到底是什么，相关需求、文档、历史讨论、代码位置和已有约束在哪里，哪些文件可以动、哪些行为不能变，跑哪些测试、看哪些截图、比对哪些指标，以及 Agent 做完之后产物应该回到哪里。如果这些问题不先设计清楚，所谓“从研发系统派活给 Agent”，很容易变成另一个聊天入口。

**这也是为什么运行时和 Harness 会变得重要。**Vercel AI SDK 7 里引入了 HarnessAgent，提供统一 API 来运行 Claude Code、Codex、Pi 等已有 agent harness；这些 harness 可以配置 sandbox、custom instructions、skills 和 tools，并支持 session 创建、恢复、中断和继续。当 Agent 不只是聊几句，而是要执行真实任务时，系统必须知道它在哪里跑、用什么工具、读哪些上下文、如何中断、如何恢复，以及如何把结果交回来。《Vercel AI SDK 7》

**GitHub 这周的一组更新也在补类似链路。**Copilot CLI 新终端界面 GA 后，可以在终端里浏览 issues、pull requests 和 gists，并把 issue 或 PR 引用放进 prompt，让 Copilot 去 investigate、fix、comment 或 review；GitHub Desktop 3.6 则把 Copilot 接进 commit authoring、merge conflict resolution 和 worktrees。它们解决的不是单点能力，而是 Agent 如何更自然地进入执行、提交、并行和验证流程。《Copilot CLI: New terminal interface is generally available》

**如果 Agent 开始从研发系统里接任务，组织就要重新设计“派活方式”。**什么样的需求单可以直接交给 Agent？什么样的 bug 可以由 Agent 先尝试修复？什么样的 PR 评论可以自动触发修改？什么样的文档讨论可以转成任务？什么样的任务必须先有人澄清，再交给 Agent？

这背后其实是一个更具体的问题：我们能不能把需求、上下文、约束、验证和责任，组织成一个 Agent 能执行、也能被人审查的任务包。

很多团队会以为，AI Coding 的瓶颈是模型不够强。但在真实研发系统里，模型只是其中一部分。**更常见的瓶颈是任务不可执行：**需求太抽象，Agent 不知道改哪里；上下文散在多个系统，Agent 只能读到一部分；验收标准不清楚，Agent 只能生成看似合理的代码；权限和边界没有定义，Agent 要么动不了关键文件，要么动得太多；结果回流没有设计，最后还是人重新整理一遍。

**所以未来真正有价值的研发自动化，不只是“让 Agent 写代码”，而是让任务在进入 Agent 之前就变得更可执行。**Issue 需要包含背景、影响范围、验收条件和相关上下文；PR Review 需要区分“必须修改”“建议优化”“风险提醒”“需要解释”；文档不只是给人看的说明，也要成为 Agent 可检索、可引用、可执行的上下文；Slack 或 IM 里的讨论，如果要进入执行链路，就需要有明确的决策沉淀。

**OpenAI 本周关于 agents 改变工作的研究里，有一个背景判断：**agentic AI 正在把知识工作的单位从单次交互，变成可委托的长周期任务；他们观察到 Codex 已经不只被工程团队使用，法务、财务、招聘等非技术部门也开始把 Codex 作为主要 AI 工具。放到研发组织里看，这意味着 Agent 不再只是在某个工具里回答问题或生成片段，而是开始承担更长、更完整、更跨系统的任务。《How agents are transforming work》

这也是为什么我觉得这周的 Signal 不是“Agent 进了更多工具”，而是“研发系统开始学习如何给 Agent 派活”。

如果用一句话概括这周的变化：Coding Agent 的下一阶段，不是生成更多代码，而是进入真实研发系统，成为任务执行的一部分。

过去是开发者调用 Agent；现在是研发系统开始给 Agent 派活。这会带来一个很实际的分水岭：AI Coding 不再只是个人效率工具，而会越来越像研发流程的一部分。谁能把需求、上下文、执行、验证和回流设计得更清楚，谁就更可能从 Agent 里获得稳定收益。

反过来，如果一个团队的需求表达、上下文沉淀、Review 规范、验证体系本来就很混乱，引入 Agent 也不会自动变好。Agent 只会把这些问题放大。

AI Coding 的竞争点，也会从“谁的工具更会写代码”，转向“谁能把真实研发系统里的任务、上下文、运行时和验证闭环接得更稳”。

真正的变化，也许不是 Agent 更像程序员了，而是研发系统开始学会给 Agent 派活。