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

Info 本文是「每周 Signal｜AI × SE」第 18 期。 本周关注：Coding Agent 的任务入口正在发生变化。它不再只是开发者在 IDE、CLI 或云端任务界面里主动唤起的工具，而是开始被 Jira、Notion、Slack、PR、Review 等真实研发系统调用，成为任务执行链路的一部分。

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

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

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

1、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[1]》

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[2]》

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

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

2、任务入口变了，上下文也变了

这里说的研发对象，不是一个新概念。它指的是需求单、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[4]》

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

3、真正难的是把任务交得清楚

把 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[5]》

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[6]》

4、研发组织要重新设计派活方式

如果 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[7]》

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

5、从调用工具，到派发任务

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

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

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

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

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

Info 「每周 Signal｜AI x SE」是我持续记录 AI 与软件工程变化的栏目。 不追热点，只记录那些正在发生、且值得长期跟踪的变化。 欢迎关注和交流～

引用链接

[1] GitHub Copilot for Jira is now generally available: https://github.blog/changelog/2026-06-25-github-copilot-for-jira-is-now-generally-available/ [2] How Notion used the Cursor SDK to embed coding agents: https://cursor.com/blog/notion [3] Introducing Claude Tag: https://www.anthropic.com/news/introducing-claude-tag [4] Teaching agents product design at Vercel: https://vercel.com/blog/teaching-agents-product-design-at-vercel [5] Vercel AI SDK 7: https://vercel.com/blog/ai-sdk-7 [6] Copilot CLI: New terminal interface is generally available: https://github.blog/changelog/2026-06-23-copilot-cli-new-terminal-interface-is-generally-available/ [7] How agents are transforming work: https://openai.com/index/how-agents-are-transforming-work/