你的团队用 AI 编程工具了吗？小心变成"个人玩具"

说实话，你们团队要是已经在用编程代理了，估计现在的情况是这样的——

程序员小张的配置连着 GitHub 自己的分支和 Linear。小李用的是另一套工具，还接入了 Sentry 和 Slack 通知。小王呢？他写了一套只有他自己能看懂的脚本，简直是"德国制造"的复杂度。

听起来很熟悉？

问题来了：有人离职怎么办？想回溯代理到底干了什么？想审计代理改的代码和实际提交的是不是一致？

基本上——没戏。

三个坑，你踩了几个？

我一直觉得，编程代理本身没问题。问题出在我们把它们当成个人编辑器在用，而不是团队的基础设施。

这直接导致三个大坑：

1. 知识孤岛 —— 只有当事人知道配置长什么样
2. 无法复现 —— 想重新跑一遍同样的任务？做梦
3. 协作障碍 —— 一个人搞定了，其他人还是白纸一张

说白了，你的"团队基础设施"，就是一堆个人快捷方式加上口口相传的"祖传知识"。

143.dev 来了：让编程代理变成团队资产

Assembled 这家公司遇到了同样的烦恼。他们的编程代理个人用着挺爽，但整个工作流一塌糊涂。

于是他们自己搭了一套系统来解决这个问题——最近还开源了，就是 143.dev。

核心理念很简单：别在每个人电脑上本地跑代理了，放到标准化环境里，大家都能用。

具体怎么做？

多代理统一管理。 什么 Codex、Claude Code、OpenCode，都能在 gVisor 沙箱里跑。想用哪个用哪个，成本、能力、任务类型自己选。Assembled 团队用 GLM 5.2 处理日常自动化（便宜快），用 Codex 或 Claude Code 做复杂的手动工作。同一套基础设施，灵活切换。

开箱即用的集成。 GitHub、Linear、Sentry、Slack、PagerDuty……都给你接好了。代理不是在真空里跑，而是真正融入你现有的工作流。

安全不折腾。 gVisor 沙箱提供隔离，不用管理一堆虚拟机那么费劲。代理能干该干的活，但都被限制在沙箱里。

MIT 协议，可自托管。 不是那种你得把代码交给他们的 SaaS。想审计？自己跑？想魔改？随你。Assembled 借鉴了 Stripe 的 Minions 和 Ramp 的 Inspect 系统，但想做一套社区也能用、也能改的东西。

为什么初创公司和成长型团队要关注？

编程代理只会越来越普及。随着团队扩张，"个人脚本"那套玩法迟早要爆。

你需要的是：

• 审计日志 —— 代理到底改了什么？
• 可复现性 —— 能不能再来一遍？
• 知识共享 —— 团队里谁都能用
• 安全性 —— 代理只能访问该访问的东西

143.dev 直接解决这些问题。而且开源意味着你不用赌一家可能两年后就不存在的公司。

说到底，这是基础设施的事

我们正在进入一个 AI 编程工具不再是"新鲜玩意儿"的时代——它们就是基础设施。

而基础设施，就该按基础设施的方式管理：透明、可复现、团队共享。

个人编程代理是起点。团队化管理的基础设施，才是真正有意思的地方。

如果你在做初创公司，或者在管工程团队，值得去看看 143.dev。GitHub 上有代码，MIT 协议。没有供应商锁定，没有隐藏费用——就是一套你可以按自己团队需求改造的开放基础设施。

有时候，最好的内部工具，就是值得分享出去的那种。

地址：143.dev | GitHub：Assembled/143.dev