Coding Agent 下半场：从个人提效到组织级研发体系

Coding Agent 下半场：从个人提效到组织级研发体系 Coding Agent 下半场：从个人提效到组织级研发体系 Modified June 15 Code block Plain Text Copy HarnessAgent.builder() .stateStore(RedisAgentStateStore.builder().lettuceClient(redisClient).build()) .build(); 切到 Redis 之后：节点崩了会话漂到另一个节点，滚动发布时旧 pod 自动保存、新 pod 自动恢复，甚至在 GitHub Issue 里聊到一半切到钉钉继续——只要 sessionId 一致，记忆都在。 组织级特有的工程问题 Cloud Native 上面讲的沙箱、恢复、记忆、持久化，是让一个 Coding Agent“能在生产环境跑住”的基础设施。但组织级的场景还有一些独有的问题需要解决。 ▍ 多通道接入：同一个 Agent 接得住所有入口 Stripe 的 Minions 走 Slack，Coinbase 的 Cloudbot 也走 Slack，Open SWE 同时接 Slack + Linear + GitHub。组织级 Coding Agent 的一个共识是：不要让用户换到一个新的界面去找 Agent，让 Agent 出现在用户已经在用的地方。 Coding Agent 在 AgentScope Harness 之上加了一层 通道适配器 ，把不同入口的事件统一映射到（ threadId, message ) ： Code block Plain Text Copy github:issue:owner/repo 42 → SHA 256 → UUID → coding agent thread dingtalk:<appKey :<staffId → SHA 256 → UUID → coding agent thread feishu:<tenantKey :<chatId → SHA 256 → UUID → coding agent thread 这个确定性映射保证同一个 Issue 的所有评论都路由到同一个 Agent session —— 对话历史自动恢复，不用用户操心。 ▍ 多租户隔离：谁和谁不能串 个人工具不需要考虑这个问题——只有一个用户，所有状态天然是隔离的。组织级服务从第一天起就是多租户的：几十个 Issue、几十个 PR、几十个 IM 对话同时在跑，每个都有自己的代码仓库、依赖目录、对话历史和长期记忆，绝不能串台。 AgentScope Harness 用 IsolationScope 控制隔离粒度。 SESSION （默认）让每个 sessionId 独立一个沙箱 —— 对 Coding Agent 来说就是每个 Issue / PR / IM 对话各跑各的，最自然也最安全。 USER 让同一用户的多个对话共享同一份仓库克隆，适合“个人工作台”场景。隔离不只是沙箱层面的 —— 会话状态、记忆、子 Agent 任务也都按同样的粒度隔离，不用开发者自己操心。 ▍ 并发控制：一个 thread 同一时间只跑一个推理 Coding Agent 用 RunDispatcher + MessageQueueHook 强制保证这一点。用户在 Agent 跑着的时候又评了一条，新消息不会打断当前推理，而是入队等下一轮开始前注入 —— 就像 Open SWE 的 check message queue before model middleware。 同时 ThreadBudgetHook 管住每个 thread 的模型调用上限， ModelCallLimitHook 管住全局 —— 一个用户的失控循环不能把全公司的额度烧光。 ▍ 工作区：人格、记忆、技能都是文件 AgentScope Harness 把所有跨调用、跨重启需要保留的东西组织成一个目录 —— workspace。行业里现在把这类设计叫“Context Engineering”。有意思的是，几乎所有主流 Coding Agent 都独立走到了同一个模式：Claude Code 有 CLAUDE.md ，GitHub Copilot 有 .github/copilot instructions.md ，Open SWE 有 AGENTS.md ——repo 级别的规约不应该硬编码在 system prompt 里，而应该是文件，能版本化、能 CR、能独立更新。 Code block Plain Text Copy /.agentscope/codingagent/workspace/ ├── AGENTS.md ← 人格 + 行为约定 ├── MEMORY.md ← 长期记忆 ├── skills/ ← 可复用技能（提交规范、测试规范等 SOP） ├── subagents/ ← 子 agent 声明 ├── knowledge/ ← 领域知识（API 文档、代码规范） └── plans/ ← Plan Mode 计划文件 三个工程价值： 团队规范以文件形式生效。 想让所有 PR 遵循 commit message 规范？写成一份 skill 放进 skills/commit style/SKILL.md ，所有 Agent 实例下次 call() 就生效，不用重启、不用改代码。 Agent 在用的过程中越来越懂团队。 第一次它问“我们用哪个测试框架”，你告诉它“JUnit 5 + Mockito”。下次 call() 它就记得了 —— 所有用同一 workspace 的对话都受益。 workspace 当 Git 管理。 AGENTS.md + skills/ + subagents/ + knowledge/ 是 Agent 的“配置仓库” —— 用 Git 管理，CI 验证，部署时 hydrate 进所有副本。频繁变化的应该是 workspace 里的内容，而不是 Java 代码。 ▍ 子 agent：把独立任务委派出去 Open SWE 用 Deep Agents 的 task tool 做子 Agent 派发，Stripe 的 Minions 用 Blueprints 编排，Ramp 的 Inspect 用 Sessions + Child Sessions。AgentScope Harness 也支持子 Agent，而且用法很轻量 —— 在 workspace 里写一个 markdown 文件就行： Code block YAML Copy workspace/subagents/researcher.md description: 调研子 agent。当需要先了解一个外部仓库或文档再做修改时使用。 workspace: mode: isolated tools: [read file, grep files, fetch url, web search] 你是调研助手。fetch url / web search 收集材料，read file / grep files 看代码， 给主 agent 一份带要点和引用的简报。 主 Agent 调用 agent spawn agent id="researcher" task="调研 ABC 库的 v2 升级要点" ，子 Agent 在隔离上下文里跑完，结果返回给主 Agent。后台调用加个 timeout seconds=0 ，主 Agent 不 block，跑完后框架自动把结果注入下一轮推理。 ▍ Plan Mode：大改之前先想清楚 让 Coding Agent 直接上手做“重构整个鉴权模块”是高风险的 —— 它可能边想边改、改坏一片。AgentScope Harness 的 Plan Mode 把这件事固化成“先想 → 写计划 → 人确认 → 再动手”的流程。开启后 Agent 进入只读阶段，只能调用读取工具和 plan 相关的四个白名单工具，退出 plan 需要人类确认。 这和 Coinbase Cloudbot 的“Agent Councils”理念类似 —— 在高风险操作前加入人类审批节点，用流程约束代替“祈祷模型别出错”。 ▍ 工具精选与确定性兜底 Stripe 在公开分享 Minions 经验时提过一个观察：他们的 Agent 有约 500 个工具，但强调“tool curation matters more than tool quantity” —— 工具不是越多越好，精选和维护比堆数量重要。Open SWE 也跟进了这个理念，只暴露约 15 个核心工具。Harness 的做法类似，内置工具集控制在文件操作 + shell 执行 + 记忆检索这个范围内，业务工具通过 toolkit.register(...) 按需注册。 另一个行业共识是： 不能只靠 prompt 告诉模型“记得跑测试”，关键步骤要用确定性逻辑保证。 GitHub Copilot Coding Agent 跑完后走 repo 现有的 CI pipeline 做验证；Open SWE 有一个 open pr if needed middleware 作为兜底——Agent 忘了开 PR，middleware 自动补上。Harness 的 middleware 机制（ MessageQueueHook 、 ThreadBudgetHook 等）也是同一思路：哪些事交给模型决定，哪些事用确定性代码保证，这条线要画清楚。 还有一点值得提： Draft PR 作为输出契约 。 无论是 Copilot Coding Agent、Open SWE 还是 Stripe Minions，Agent 的产出都是 draft PR，永远需要人类 review 后才能 merge。Agent 不直接改生产代码——这是组织级 Coding Agent 的一个基本安全假设。 从单机到企业：一条演进路线 Cloud Native AgentScope Harness 让你从最简的形态开始，按需切换 —— 同一份 Agent 代码逻辑，配置不同就跑出不同的能力。 Stage 1：本机 CLI。 什么都不配。 execute 在宿主 sh c 跑，状态存本地文件。只在你信任的本机环境用 —— 这就是一个能装记忆、能装技能的加强版本地 Coding Agent。 Stage 2：本机 + Docker 沙箱。 加一行 .filesystem(new DockerFilesystemSpec()...) ，所有执行进容器。这是给 GitHub Webhook 模式用的——每个 Issue/PR 一个临时容器，宿主不暴露攻击面。 Stage 3：多副本 + 分布式。 stateStore 换 Redis，沙箱快照存 OSS，加 executionGuard 做并发控制。到这一步 Coding Agent 就能横向扩展——挂在负载均衡器后面跑 N 个副本，任何副本都能接住任何用户的任何对话。 Code block Plain Text Copy .filesystem(new DockerFilesystemSpec() .image("agentscope/coding sandbox:latest") .isolationScope(IsolationScope.USER) .snapshotSpec(new OssSnapshotSpec(ossClient, "bucket", "prefix/")) .executionGuard(RedisSandboxExecutionGuard.builder(jedis) .leaseTtl(Duration.ofMinutes(30)).build())) .stateStore(RedisAgentStateStore.builder().lettuceClient(redisClient).build()) Stage 4：可观测与限流。 Spring Boot Actuator 暴露健康探针和 Prometheus 指标， ThreadBudgetHook 和 ModelCallLimitHook 守住模型预算， FallbackModel 应对上游限流。这些组合在一起就是一个“上线后能跑住”的 Coding Agent 应该有的样子。 总结 Cloud Native 回顾一下本文提到的这些项目 —— Stripe Minions、Ramp Inspect、Coinbase Cloudbot、LangChain Open SWE、GitHub Copilot Coding Agent、Claude Code，再加上 AgentScope Harness —— 它们在语言、生态、部署形态上各不相同，但在核心架构决策上高度一致：per session 隔离沙箱、确定性的 thread ID 路由、middleware 拦截链、Agent 运行时的 message queue 注入、repo 级指令文件、draft PR 作为输出契约。 Coding Agent 的上半场是个人提效 —— 模型更聪明、补全更准、本地工具更顺手。下相半场的战场转到了工程：怎么把“能跑一次 demo”变成“7×24 稳定服务一整个团队”。从 Stripe 到 GitHub，从 LangChain 到 AgentScope，大家在不同的起点上走向了同的架构。这种趋同本身就是最好的路标。 文中提到的 Coding Agent 是一个完整且可读的示例，但还远不是一个生产可用的产品，建议直接 clone 下来跑一遍再翻源码 —— 它把本文讲的这些工程问题都对应到了真实代码去完善它。 想继续深入了解，推荐大家深入了解 AgentScope 2.0 官方文档： https://java.agentscope.io 切到 Redis 之后：节点崩了会话漂到另一个节点，滚动发布时旧 pod 自动保存、新 pod 自动恢复，甚至在 GitHub Issue 里聊到一半切到钉钉继续——只要 sessionId 一致，记忆都在。 组织级特有的工程问题 Cloud Native 上面讲的沙箱、恢复、记忆、持久化，是让一个 Coding Agent“能在生产环境跑住”的基础设施。但组织级的场景还有一些独有的问题需要解决。 ▍ 多通道接入：同一个 Agent 接得住所有入口 Stripe 的 Minions 走 Slack，Coinbase 的 Cloudbot 也走 Slack，Open SWE 同时接 Slack + Linear + GitHub。组织级 Coding Agent 的一个共识是：不要让用户换到一个新的界面去找 Agent，让 Agent 出现在用户已经在用的地方。 Coding Agent 在 AgentScope Harness 之上加了一层 通道适配器 ，把不同入口的事件统一映射到（ threadId, message ) ： 这个确定性映射保证同一个 Issue 的所有评论都路由到同一个 Agent session —— 对话历史自动恢复，不用用户操心。 ▍ 多租户隔离：谁和谁不能串 个人工具不需要考虑这个问题——只有一个用户，所有状态天然是隔离的。组织级服务从第一天起就是多租户的：几十个 Issue、几十个 PR、几十个 IM 对话同时在跑，每个都有自己的代码仓库、依赖目录、对话历史和长期记忆，绝不能串台。 AgentScope Harness 用 IsolationScope 控制隔离粒度。 SESSION （默认）让每个 sessionId 独立一个沙箱 —— 对 Coding Agent 来说就是每个 Issue / PR / IM 对话各跑各的，最自然也最安全。 USER 让同一用户的多个对话共享同一份仓库克隆，适合“个人工作台”场景。隔离不只是沙箱层面的 —— 会话状态、记忆、子 Agent 任务也都按同样的粒度隔离，不用开发者自己操心。 ▍ 并发控制：一个 thread 同一时间只跑一个推理 Coding Agent 用 RunDispatcher + MessageQueueHook 强制保证这一点。用户在 Agent 跑着的时候又评了一条，新消息不会打断当前推理，而是入队等下一轮开始前注入 —— 就像 Open SWE 的 check message queue before model middleware。 同时 ThreadBudgetHook 管住每个 thread 的模型调用上限， ModelCallLimitHook 管住全局 —— 一个用户的失控循环不能把全公司的额度烧光。 ▍ 工作区：人格、记忆、技能都是文件 AgentScope Harness 把所有跨调用、跨重启需要保留的东西组织成一个目录 —— workspace。行业里现在把这类设计叫“Context Engineering”。有意思的是，几乎所有主流 Coding Agent 都独立走到了同一个模式：Claude Code 有 CLAUDE.md ，GitHub Copilot 有 .github/copilot instructions.md ，Open SWE 有 AGENTS.md ——repo 级别的规约不应该硬编码在 system prompt 里，而应该是文件，能版本化、能 CR、能独立更新。 三个工程价值： 团队规范以文件形式生效。 想让所有 PR 遵循 commit message 规范？写成一份 skill 放进 skills/commit style/SKILL.md ，所有 Agent 实例下次 call() 就生效，不用重启、不用改代码。 Agent 在用的过程中越来越懂团队。 第一次它问“我们用哪个测试框架”，你告诉它“JUnit 5 + Mockito”。下次 call() 它就记得了 —— 所有用同一 workspace 的对话都受益。 workspace 当 Git 管理。 AGENTS.md + skills/ + subagents/ + knowledge/ 是 Agent 的“配置仓库” —— 用 Git 管理，CI 验证，部署时 hydrate 进所有副本。频繁变化的应该是 workspace 里的内容，而不是 Java 代码。 ▍ 子 agent：把独立任务委派出去 Open SWE 用 Deep Agents 的 task tool 做子 Agent 派发，Stripe 的 Minions 用 Blueprints 编排，Ramp 的 Inspect 用 Sessions + Child Sessions。AgentScope Harness 也支持子 Agent，而且用法很轻量 —— 在 workspace 里写一个 markdown 文件就行： 主 Agent 调用 agent spawn agent id="researcher" task="调研 ABC 库的 v2 升级要点" ，子 Agent 在隔离上下文里跑完，结果返回给主 Agent。后台调用加个 timeout seconds=0 ，主 Agent 不 block，跑完后框架自动把结果注入下一轮推理。 ▍ Plan Mode：大改之前先想清楚 让 Coding Agent 直接上手做“重构整个鉴权模块”是高风险的 —— 它可能边想边改、改坏一片。AgentScope Harness 的 Plan Mode 把这件事固化成“先想 → 写计划 → 人确认 → 再动手”的流程。开启后 Agent 进入只读阶段，只能调用读取工具和 plan 相关的四个白名单工具，退出 plan 需要人类确认。 这和 Coinbase Cloudbot 的“Agent Councils”理念类似 —— 在高风险操作前加入人类审批节点，用流程约束代替“祈祷模型别出错”。 ▍ 工具精选与确定性兜底 Stripe 在公开分享 Minions 经验时提过一个观察：他们的 Agent 有约 500 个工具，但强调“tool curation matters more than tool quantity” —— 工具不是越多越好，精选和维护比堆数量重要。Open SWE 也跟进了这个理念，只暴露约 15 个核心工具。Harness 的做法类似，内置工具集控制在文件操作 + shell 执行 + 记忆检索这个范围内，业务工具通过 toolkit.register(...) 按需注册。 另一个行业共识是： 不能只靠 prompt 告诉模型“记得跑测试”，关键步骤要用确定性逻辑保证。 GitHub Copilot Coding Agent 跑完后走 repo 现有的 CI pipeline 做验证；Open SWE 有一个 open pr if needed middleware 作为兜底——Agent 忘了开 PR，middleware 自动补上。Harness 的 middleware 机制（ MessageQueueHook 、 ThreadBudgetHook 等）也是同一思路：哪些事交给模型决定，哪些事用确定性代码保证，这条线要画清楚。 还有一点值得提： Draft PR 作为输出契约 。 无论是 Copilot Coding Agent、Open SWE 还是 Stripe Minions，Agent 的产出都是 draft PR，永远需要人类 review 后才能 merge。Agent 不直接改生产代码——这是组织级 Coding Agent 的一个基本安全假设。 从单机到企业：一条演进路线 Cloud Native AgentScope Harness 让你从最简的形态开始，按需切换 —— 同一份 Agent 代码逻辑，配置不同就跑出不同的能力。 Stage 1：本机 CLI。 什么都不配。 execute 在宿主 sh c 跑，状态存本地文件。只在你信任的本机环境用 —— 这就是一个能装记忆、能装技能的加强版本地 Coding Agent。 Stage 2：本机 + Docker 沙箱。 加一行 .filesystem(new DockerFilesystemSpec()...) ，所有执行进容器。这是给 GitHub Webhook 模式用的——每个 Issue/PR 一个临时容器，宿主不暴露攻击面。 Stage 3：多副本 + 分布式。 stateStore 换 Redis，沙箱快照存 OSS，加 executionGuard 做并发控制。到这一步 Coding Agent 就能横向扩展——挂在负载均衡器后面跑 N 个副本，任何副本都能接住任何用户的任何对话。 Stage 4：可观测与限流。 Spring Boot Actuator 暴露健康探针和 Prometheus 指标， ThreadBudgetHook 和 ModelCallLimitHook 守住模型预算， FallbackModel 应对上游限流。这些组合在一起就是一个“上线后能跑住”的 Coding Agent 应该有的样子。 总结 Cloud Native 回顾一下本文提到的这些项目 —— Stripe Minions、Ramp Inspect、Coinbase Cloudbot、LangChain Open SWE、GitHub Copilot Coding Agent、Claude Code，再加上 AgentScope Harness —— 它们在语言、生态、部署形态上各不相同，但在核心架构决策上高度一致：per session 隔离沙箱、确定性的 thread ID 路由、middleware 拦截链、Agent 运行时的 message queue 注入、repo 级指令文件、draft PR 作为输出契约。 Coding Agent 的上半场是个人提效 —— 模型更聪明、补全更准、本地工具更顺手。下相半场的战场转到了工程：怎么把“能跑一次 demo”变成“7×24 稳定服务一整个团队”。从 Stripe 到 GitHub，从 LangChain 到 AgentScope，大家在不同的起点上走向了同的架构。这种趋同本身就是最好的路标。 文中提到的 Coding Agent 是一个完整且可读的示例，但还远不是一个生产可用的产品，建议直接 clone 下来跑一遍再翻源码 —— 它把本文讲的这些工程问题都对应到了真实代码去完善它。 想继续深入了解，推荐大家深入了解 AgentScope 2.0 官方文档： https://java.agentscope.io 🔗 原文链接： https://mp.weixin.qq.com/s/LA1AFSjb... https://mp.weixin.qq.com/s/LA1AFSjb... 原创 AgentScope 社区 AgentScope 社区 阿里云云原生2026年6月12日 18:30 浙江 当下还在古法手搓代码的开发者都是在奔着非遗传承人的目标去了，绝大多数都已经用上了 Claude Code、Cursor 这类 Coding Agent。方向对了，但场景不同，解法也不同 —— 开发者自己在本地装个 AI 助手提效，和在组织内部搭起一套 AI 驱动的研发协作体系，是完全两个维度的事情。前者已经有成熟的产品了，后者才刚刚开始。本文聊的就是后者。 什么是组织级 Coding Agent， 都有谁在做？ Cloud Native 2025 年底到 2026 年初，一件有意思的事情发生了：Stripe、Ramp、Coinbase 这三家公司几乎同时公开了各自的内部 Coding Agent —— Stripe 叫 Minions ，Ramp 叫 Inspect，Coinbase 叫 Cloudbot。三家公司独立开发，没有互相参考，最终却不约而同地收敛到了几乎相同的架构上。 这不是巧合。当你把 Coding Agent 从“一个人在终端里用”升级成“整个团队通过 Slack / GitHub Issue 随时触发”，你就会被同一组工程问题逼到同一条路上去——你需要沙箱隔离执行环境，需要让 Agent 在中断后能续上之前的工作，需要让它接得住 Slack、GitHub、飞书各种入口，需要防止一个用户的失控循环把全公司的模型额度烧光。 LangChain 团队看到了这个规律。2026 年 3 月，他们发布了 Open SWE —— 一个把 Stripe/Ramp/Coinbase 的共同模式提炼成开源框架的项目。Open SWE 的 README 开头写得很直接： Elite engineering orgs like Stripe, Ramp, and Coinbase are building their own internal coding agents — Slackbots, CLIs, and web apps that meet engineers where they already work. "Meet engineers where they already work" —— 这句话点出了组织级 Coding Agent 的核心设计理念：不是让工程师学一个新工具，而是让 Agent 钻进工程师已经在用的 Slack 频道、GitHub Issue、IM 对话里，变成团队工作流的一部分。 AgentScope Java 2.0 的 AgentScope Harness 模块走的是同一条路。本文以官方示例 agentscope examples/agents/agentscope codingagent 为线索，讲清楚一个生产级 Coding Agent 是怎么用 Harness 拼出来的 —— 每一行配置解决了什么问题，怎么从本地 CLI 一路演进到挂在 GitHub Webhook 后面的企业服务。 先把定位说清楚 Cloud Native 在往下走之前，必须把“我们要做的”和“Claude Code / Cursor 这类本地工具”区分清楚。 Claude Code 优化的是“ 我一个人写代码更快” —— 你打字、它干活、你看着它干活、你随时打断纠正。状态在你本机，触发者就是你自己，信任边界就是你信你自己的机器。 本文要搭的东西解决的是另一个问题：“ 团队里某个小任务我都不用自己看，扔给 Agent 跑完开 PR 我 review 一下就行” 。 触发者可能是任何一个 Issue 评论者，Agent 在远端跑十几分钟到一小时，没人盯着。Stripe 的工程师在 S