异步编码代理工作流

解决的问题

当代码变更需要跨多个入口流转时，传统做法是让工程师反复在 GitHub Issues、Slack 频道和 Linear 看板之间手动搬运上下文：读需求、拉分支、写代码、跑测试、提 PR。一旦任务量上升，这种人工中转就成了瓶颈，而且容易丢失上下文。

技能如何工作

这个技能的核心思路是部署一个内部编码代理，让它接管从任务接收到 PR 提交的完整链路。

• 触发来源：支持 GitHub、Slack 和 Linear 三种入口，代理会监听对应事件并拉取任务描述。
• 沙箱执行：每个任务都在隔离的 sandbox 中运行，避免污染本地环境或共享依赖。
• 自动产出：代理在沙箱内完成代码修改、测试运行，并在完成后自动打开 pull request，供人工 review。

关键步骤包括：配置 GitHub App 以获得仓库读写权限；接入 LangSmith 做可观测性追踪；选择 sandbox provider 决定执行环境；最后为 Slack、Linear 或 GitHub 设置对应的 trigger。

适用边界与注意点

这套方案适合规则相对明确、改动范围可控的内部任务，例如修 bug、补测试、更新依赖。对于需要深度架构决策或强交互的场景，代理产出的 PR 仍需人工介入。

同时，sandbox 的选择直接影响执行成本和隔离强度，建议根据团队现有的基础设施来决定。自定义 system prompt 和 middleware 时，也要确保代理行为与组织规范对齐，否则自动提交的 PR 可能引入新的治理负担。