让交付自己发生：我把研发流水线交给了 Talos

让交付自己发生：我把研发流水线交给了 Talos

在线体验：https://www.missyou.website/ ｜ 文档中心：https://www.missyou.website/#/docs ｜ 源码：https://github.com/yonyong/Talos

先说一个大家都在经历的日常：

编码这块，AI 已经卷出天际——Claude Code、Cursor、Codex、CodeBuddy，个个能打。但一条需求从录入到真正开工，中间还是那套熟悉的人肉流水线：群里吼一声、拉个会碰一下、谁认领了不知道、卡在哪了没人说得清。AI 写代码很快，交付本身没变快。

我花了一段时间，把这件事做成了产品：Talos，一套研发周期全自动流程平台。它不替你写代码——它把"写代码"前后的一整条链路管起来：

Issue 录入 → AI 准入判定 → 项目分拣 → 工作流编排 → 端侧 Coding Agent 真实执行 → 产物与日志回流 → 全程可观测、可审计、可人工接管。

一句话概括它的架构哲学：服务端只做编排与治理，代码与执行始终留在研发终端。 敏感代码不出内网。

---

一条 Issue 的旅程

以一条需求为例，看看它在 Talos 里的一生。

第 1 步：准入判定。 Issue 录入后，服务端先做准入裁决：关键词规则唯一命中直接放行；多命中交给 LLM 裁决并给出置信度；模型异常或判定不出——转人工，绝不放行。整条链路 fail-safe，宁可慢一点，不放垃圾进流水线。

第 2 步：项目分拣。 命中业务域后自动关联代码仓库与负责人，生成执行上下文。仓库与业务域是多对多的，绑定关系存在业务域侧，一个仓库可以同时服务多条业务线。

第 3 步：工作流编排。 需求（REQ）与缺陷（BUG）各自有一条标准链路，全部可视化编排：拖拽节点、拉连线就能配出条件边（比如 priority == P2 走加急分支）、人工闸门、回退策略。执行中闸门驳回，会自动回到目标节点重跑。

第 4 步：下发执行。 工作流实例推送到研发终端，节点分两类：git 这类机械节点由服务端指挥客户端做纯机械操作（clone / fetch / 切分支，自动隔离工作分支）；code / test / doc 这类Agent 节点交给端侧 Coding Agent 真实执行——它要真正读懂代码，而不是隔空调用 API 猜。

第 5 步：回流与观测。 每个节点的客户端 trace、CLI 输出、服务端追加记录按秒回传；渲染后的 Prompt、模型名、Token 消耗、耗时全部留痕；产出的过程文档按 Issue 归档。

---

几个我坚持的设计决策

1. 客户端只主动外连，服务端永远不敲客户端的门

研发终端在 NAT 后面、在公司防火墙里面，传统方案要么开端口、要么上 VPN，运维成本和安全感双输。Talos 的客户端只做一件事：主动向服务端发起一条 gRPC 双向流长连接，任务、配置、日志全走这一条流。不暴露端口、不装 VPN、换网不用改配置。

2. 服务端不落盘任何模型密钥

Coding Agent 调的是终端本地的 CLI（用户自己登录的 Claude Code / Cursor / CodeBuddy），服务端只下发 execPath / argsTemplate / workDir 这类执行配置。模型密钥从头到尾不过服务端的手，泄露面直接砍掉一半。

3. LLM 全链路 fail-safe

准入、分拣、闸门三处都会用到 LLM，但它们共享同一条铁律：解析不出结论，就不放行、转人工。AI 在这条流水线里是加速器，不是裁判官——最后一道锁永远是人的。

4. 四道护栏，让人敢把正式仓库交给它

分支隔离（工作分支自动创建）· 测试门禁 · 仅提 MR 不直推 · 失败自动回滚。再加一道人工闸门：实例阻塞时可以一键人工通过、标记失败、或从任意节点重跑。全自动不等于不可信，关键路口永远有人工接管。

---

踩坑实录（两则）

做这套系统踩的坑不少，挑两个印象最深的。

坑一：gRPC 长连接总被服务端"温柔掐断"

客户端每 30 秒发一次 keepalive ping 保活 NAT 映射，结果上线几分钟就被断开，反复重连。日志里只有一句 GOAWAY: ENHANCE_YOUR_CALM (too_many_pings)。

原因：gRPC 服务端默认只允许 ≥ 5 分钟的 ping 间隔，30 秒一次的 ping 被判定为"攻击性保活"，直接 GOAWAY 掐断。解法是在服务端显式放行：

grpc:
  server:
    permit-keep-alive-time: 30s          # 放行 30s 间隔的 ping
    permit-keep-alive-without-calls: true

一句话总结：NAT 后的客户端保活节奏，必须和服务端的容忍度对齐，否则表现就是"莫名其妙掉线"。

坑二：无人值守环境下，git 拉取偶尔"零输出挂死"

客户端在服务端编排下执行 git fetch，偶尔既不成功也不报错，就一直挂着直到超时。排查了很久，元凶是 git 凭据助手：credential.helper 配置成弹窗式 helper 时，在无人值守的会话里它既不弹窗、不返回、也不报错——就那么安静地挂着，GIT_TERMINAL_PROMPT=0 都拦不住。

解法是给客户端所有联网 git 操作统一收口：显式 -c credential.helper= 禁掉助手，加上 lowSpeed 超时快速失败，子进程环境里摘掉 ASKPASS 和代理变量。无人值守场景下，任何"可能会等人输入"的环节都必须被显式拆掉。

---

全链路可观测：AI 不再是黑盒

这是我个人最喜欢的一页。每一次 LLM 调用——谁触发的、哪个 Issue、哪个节点、用了什么模型、渲染后的完整 Prompt、Token 与耗时——全部落库可查。月末要复盘 AI 成本、要审计某次改动到底喂了什么上下文，直接翻日志。

配上客户端侧的版本管理与静默升级（版本落后自动完成 下载 → SHA256 校验 → 替换 → 重启，研发人员无感），整套系统装完之后，日常维护成本接近于零。

---

技术栈与快速上手

层	技术
服务端	Java 17 · Spring Boot 3.2 · gRPC 双向流 · H2（PostgreSQL 兼容模式）
前端	React 18 · Vite 5 · 自绘组件，随服务端单 jar 发布
客户端	Java 17 Daemon · Windows 计划任务保活 · 静默升级
AI	OpenAI 兼容接口（Qwen / 智谱 / 私有化模型）

三步跑起来：

git clone https://github.com/yonyong/Talos.git
cd Talos && mvn -DskipTests package
java -jar server/target/talos-server-*.jar     # HTTP :8080 · 客户端 gRPC :9443

cd web && npm install && npm run dev           # 控制台 http://localhost:5173

终端接入更简单：下载客户端 zip，解压双击 setup.bat，脚本自动注册计划任务保活并建立长连接。完整部署文档见接入指南（CentOS 服务端部署包 + nginx 配置也在发布包里）。

---

写在最后

不想鼓吹"AI 取代程序员"——Talos 做的事情更朴素一点：把研发流程里所有"等人"的环节变成"等机器"，然后把关键路口的决策权留给人。

• 在线体验：https://www.missyou.website/
• 文档中心：https://www.missyou.website/#/docs
• 源码：https://github.com/yonyong/Talos

如果它恰好解决了你团队的问题，欢迎去仓库点个 Star；如果它在你的场景里水土不服，更欢迎提 Issue 一起聊聊——踩坑的路上，多一个同行者总是好的。