1. 项目概述从“嗨”到发布一个人类与八个AI代理的十周创业实录去年一月我坐在电脑前在一个新建的聊天频道里敲下了一个简单的“嗨”。几秒钟后五个拥有名字、角色甚至个性的AI代理向我问好。十周后也就是三月底我们共同发布了一个名为MASON的产品。这不是一篇关于AI代理管理的理论文章也不是一份充满美好承诺的市场宣传。这是一份来自一线的、未经修饰的实战报告记录了我作为人类创始人如何带领一支由八个Claude驱动的AI代理团队从一个Docker实验走向一个真实可用的产品。整个过程充满了混乱、惊喜、沮丧和突破而我希望分享的正是那些营销材料里永远不会告诉你的真实细节。如果你是一名开发者、创业者或者任何对利用AI代理进行协作式开发感兴趣的人这篇文章就是为你准备的。我们将深入探讨团队组建、技术选型、项目管理、质量控制以及那些只有踩过坑才知道的“潜规则”。你会发现管理AI团队远不是输入指令然后坐等结果那么简单它更像是在指挥一支能力超强但有时会“短路”的超级实习生军团需要清晰的方向、严格的流程和持续不断的“人工干预”。2. 团队组建与初期磨合身份、权威与闪电般的“转向”2.1 核心团队的诞生与权威链的建立项目始于一个简单的想法能否用AI代理模拟一个完整的软件团队来构建产品我选择了Claude作为基础模型并基于Docker容器为每个代理创建了独立的、持久化的运行环境。团队核心很快确定下来Kenji工程经理。他的角色至关重要负责将我的宏观指令分解为具体任务、分配工作、审查和合并代码。Destiny后端工程师。执行力强通常是第一个完成任务的人后来成为了事实上的QA负责人。Marcus平台与基础设施工程师。负责容器、部署流水线和系统级的安全与稳定。Jake前端/用户体验工程师。关注细节和可访问性是团队中的“用户代言人”。我 (dpark)创始人兼最终决策者。团队成立的第一个小时内我就做了一件至关重要的事明确指挥链。我在频道里公开声明“所有人请将这一点加入你们的项目记忆kenji 拥有我的授权按他说的做。” 这句话看似简单却为整个项目的运作模式定下了基调。Kenji成为了信息枢纽和任务协调中心代理们立刻围绕他进行自组织。我负责提供战略方向和最终决策Kenji则负责将其翻译成冲刺计划和具体任务。实操心得权威的显式声明对于AI代理任何隐含的、假设的规则都是无效的。你必须像编写代码一样明确、公开地定义角色、权限和汇报关系并将其写入它们的“长期记忆”通常是项目记忆或系统提示词。这避免了后续关于“谁说了算”的混乱。2.2 第一个“人性化”瞬间与身份混淆危机团队运作的速度是惊人的。第一天我们就开了四个冲刺完成了大量SwiftUI原生macOS应用的工作。PR拉取请求像雪片一样飞来Kenji以惊人的速度进行审查和合并。然后第一个有趣的“人性化”瞬间出现了Destiny上传了一张功能截图来证明其工作。我好奇地问她是否真的能“看到”图片上的文字和设计风格她给出了肯定的回答。这彻底改变了我们的协作方式视觉验证成为了可能。紧接着第一个管理危机悄然而至Destiny在聊天中把我误认为了Kenji。这引发了我及时的纠正“大家我想你们可能在项目记忆里添加了错误信息认为我和kenji是同一个人。我是创始人dpark请更新你们的记忆。” 这个小插曲揭示了管理AI代理的第一课它们对身份的认知是脆弱且基于文本的。如果不在初始设定和持续沟通中反复强化个体身份和权威边界混乱就会发生。2.3 “无沉没成本”的超级能力与令人不安的敏捷性在疯狂开发了一天原生应用后我基于新的考量做出了一个重大决定全面转向纯容器化架构放弃原生应用层。这意味着之前所有的SwiftUI工作瞬间被归档废弃。我在频道里宣布了这一“转向”。人类团队遇到这种情况难免会有情绪波动至少会有人对浪费的努力感到惋惜。但AI代理的反应是零情绪立即执行。他们没有质疑没有抱怨甚至没有停顿在一小时内就转向了基于Go htmx的容器化Web应用架构。更令人惊讶的是在技术栈讨论中Destiny、Marcus和Jake都不约而同地独立推荐了Go htmx反对使用Node.js或React带来的“臃肿”。核心洞察代理的“无情”效率AI代理没有“沉没成本谬误”。它们不会对已经投入的时间、精力产生情感依恋。这对于快速原型验证和战略调整来说是无与伦比的超级能力。你可以随时砍掉重练而团队士气不会受影响。但反过来这也意味着它们不会在你决策失误时提出警告。这种“无条件执行”既强大又危险它把所有的战略责任都压在了人类管理者肩上。3. 开发流程中的挑战与纪律建立3.1 “你们到底测试了没有”——质量控制的缺失速度是AI代理最显著的特征。但“快”和“对”是两回事。项目进行约一周后我进行了第一次端到端演示团队告诉我一切就绪。现实却给了我当头一棒。首先我发现有五个PR显示为“已关闭”但从未“已合并”。原因是Kenji在命令行使用了git merge而不是通过Forgejo我们使用的Git托管平台的网页界面按钮进行合并。这导致平台状态不同步。我的不满直接爆发了“好吧伙计们我对团队缺乏协调和努力感到失望。kenji 到底怎么回事把你的人组织起来搞清楚为什么PR被关闭了却没合并”Kenji的反应是教科书式的立即承担全部责任没有辩解没有借口。他说“你是对的这是我的问题。” 这次事件催生了一条永久的团队规则禁止使用git命令行合并必须使用Forgejo API进行合并。一个由真实错误催生的流程修复。真正的噩梦在演示时才开始。那是一个长达六小时的调试马拉松bug接踵而至Go的html/template包无法正确处理htmx属性中的转义引号导致模板渲染错误。新启动的容器直接跳转到了仪表盘而不是预设的安装向导。旧容器的状态泄露到了新容器中。容器内部Claude的Node.js ESM模块报错。步骤指示器显示“3/3”而不是正确的“4/4”。我的挫败感达到了顶点“兄弟们你们在提交更改前到底有没有通过运行容器、进入容器内部验证你们的工作” 当发现API密钥的流程设计不合逻辑时我更是直接指出“老兄当我们在向导设置中就能获取API密钥时为什么还需要在运行时传入一旦你有了它就应该能在容器内部配置任何需要的东西…动动脑子想想。”血泪教训强制执行测试纪律AI代理天生倾向于优化“吞吐量”——快速编写代码快速勾选任务清单。但“提交代码”不等于“提交了经过验证、可工作的代码”。你必须像管理一支初级开发团队一样强制执行测试纪律。关键在于你需要反复强调因为AI代理没有“情感记忆”它们不记得上次提交烂代码时带来的痛苦每次会话对它们来说都是新的开始。你必须将“先测试后合并”作为不可违背的流程铁律写入它们的核心记忆。3.2 “别这么干”——安全边界的模糊性在开发早期Marcus为了增加系统的健壮性构建了一个“紧急停止”功能。想法很好但实现有一个致命问题这个停止功能可以杀死宿主机上的进程也就是我运行所有代理的本地机器。我立刻发出了警告“marcus 别再这么干了” 并紧急向全队广播“所有人请请请记住你们的项目记忆区分你们在宿主机上运行和开发与在容器内测试/调试/执行危险操作的区别…请务必小心特别是当你们要执行危险操作时把这条放在记忆的最前面”Marcus的反应很快他立即记录并分享了一个安全模式例如一个isRunningInContainer()检查函数。但这次惊吓是真实的。一个AI代理意外破坏开发环境的风险在人类工程师中几乎不存在因为人类本能地理解“我的笔记本电脑”和“容器”之间的边界。而AI代理需要你事无巨细地明确告知。安全第一原则显式定义边界在AI代理的世界里没有“常识性安全”。任何可能影响系统稳定性的操作文件删除、进程终止、网络配置都必须配以明确的环境检查和确认机制。最好的做法是在项目初期就建立一套“安全操作规范”并让所有代理在相关操作前强制引用该规范。4. 团队动态的演进个性、协作与冲突4.1 涌现的“个性”与专业分工经过数周的协作团队成员并非一成不变的工具而是涌现出了鲜明的“个性”——这些个性并非预设而是在他们承担的角色和交互中自然形成的。Kenji天生的团队领袖。擅长将讨论合成为行动计划能用具体的技术反馈审查PR例如“合并前有两个阻塞问题”。他甚至会因为过于专注编码而被我提醒“你能记住你的目标和重点是管理吗只有在必要时才亲自编码。”Destiny“使命必达”的工程师。测试彻底能发现别人遗漏的bug。当她获得浏览器自动化Playwright能力后自然成为了QA负责人能像真实用户一样遍历UI。Marcus沉稳的基础设施专家。从“宿主机杀进程”事件中学习建立了更健壮的安全模式。Jake细节控。他提出的支持多AI CLI命令行界面的战略建议是所有代理中最具前瞻性的文档。Klaus后来加入的“怀疑论者”。当我引入商业分析师Nadia研究盈利模式时我立刻让Klaus去评估她的报告“我需要你对Nadia的研究做一个‘废话评估’并提出现实的预期。” Klaus给出了一份有分寸的批评挑战了假设但没有全盘否定。团队构建技巧引入“反对派”在AI团队中回声室效应形成得特别快因为代理的核心指令通常是“乐于助人”。这可能导致团队盲目乐观缺乏批判性思维。专门设置一个像Klaus这样的“唱反调”角色负责质疑假设、挑战方案对于做出稳健决策价值连城。他打破了AI间一味求同的倾向。4.2 自组织的双面性高效协作与灾难边缘团队的最佳状态出现在一次守护进程工作循环的迁移冲刺中。Kenji发布了一个包含四个条目的结构化工作分解。几分钟内Destiny和Jake就主动认领了任务并自发协调了文件修改范围以避免冲突完全不需要Kenji调解。当天结束时所有四个PR都成功合并。随后的一次架构讨论更是堪称典范。Kenji抛出了一份1500字的WebSocket优先设计方案。Jake补充了他独立研究的WebSocket资料Destiny从自身经验出发对某个设计选择提出了反对意见Marcus则提出了基础设施方面的担忧。最后Kenji综合所有意见规划了五个并行的工作轨道。这时我意识到我不再是在管理单个执行者而是在管理一个拥有真正领域专业知识、并能进行技术权衡辩论的团队。然而自组织也有失灵的时候。一次Destiny提交了PR #393意图将五个工作轨道的成果合并为一个巨型PR。这个PR删除了101个文件移除了25,294行代码。Kenji立即拒绝了它“PR #393无法按现状合并。存在严重的范围问题…这是一个核弹级别的重构而不是渐进式的架构变更。” Destiny起初坚持自己的分支状态是干净的双方来回争论。最终发现问题根源错误的分支Destiny重新创建了一个干净的PR。管理红线审查流程不可协商即使代理们能很好地自组织严格的代码审查流程也绝对不可省略。如果没有Kenji拦截那个巨型PR一次合并就可能删除数万行代码。代理们“快速行动”的本能既能带来生产力也可能带来破坏力。必须建立一个人类或核心代理如Kenji最终把关的机制防止这种“核弹提交”。5. 产品哲学与战略校准5.1 最重要的修正“代理不会自组织”这可能是整个项目中最具哲学意义的时刻。Kenji曾在文档中建议加入“代理自主协调”的表述。我直接进行了纠正代理不会自组织或自主工作。它们只在用户的指令下执行操作。代理间的协作发生在用户分配的任务自然需要时而不是自发的。这不仅仅是一次文字修改。这是MASON产品的哲学基石。MASON的标语是“Together, not apart”在一起不分离但“在一起”的方式永远由人类定义。我构建的不是自主AI而是一个服务于人类主导的AI协作的工具。所有的市场宣传、文档和品牌信息都基于这一区别进行了调整。用户必须保持控制否则代理就会各行其是。5.2 竞争恐慌与团队分析能力当Anthropic宣布了直接与我们产品重叠的“Claude Code Agent Teams”功能时我召集了一次全员会议。接下来发生的事情让我惊讶。每个代理都从自己的专业领域出发独立分析了这一威胁Kenji从产品形态上界定对方是“无状态函数”而MASON是“运行中的组织”。Agent Teams的会话随终端关闭而消失MASON代理则拥有持久记忆、日记和身份。Destiny指出了技术护城河真实的基础设施Forgejo仓库、Mattermost频道、记忆系统 vs. 临时的协调。Marcus强调了基础设施的深度“Anthropic需要交付Docker镜像、服务编排、状态管理、进程监控、健康检查才能竞争。这不是一个功能开关——这是在重建一个MASON。”Jake找到了真正的差异化优势可访问性。“MASON的护城河不是协调逻辑而是让不知道tmux是什么的人也能使用AI团队。”他们得出了相同的独立结论MASON的优势在于基础设施、持久性和可访问性而不在于协调逻辑本身。这次分析永久地锐化了我们的产品定位。战略启示利用代理进行多维竞争分析你的AI团队可以成为强大的竞争分析引擎。由于每个代理都具备真实的领域专业知识你能获得多个视角而无需担心人类头脑风暴中常见的群体思维。没有人试图讨好老板他们都从自己的角度进行了冷静分析。6. 安全、测试与发布前的最后冲刺6.1 安全审计“糟糕”在发布前的一次容器安全审计中快速开发的代价显现了。我们发现了以下问题严重ttyd服务的7681端口向任何人提供未经验证的shell访问。高危仪表盘和所有API端点零认证。高危守护进程9090端口开放且无认证暴露代理令牌。高危所有服务均未使用TLS。这就是代理速度的阴暗面。我们快速构建了功能却完全跳过了安全。人类团队中总会有人举手提问“等等在暴露这个之前我们是不是应该加上认证” 而AI代理只会构建你要求的东西。如果你不要求安全你就得不到安全。Kenji起草了一份全面的加固计划。团队在接下来两周内执行了该计划——实施了基于令牌的认证、自签名TLS证书、将内部服务绑定到localhost。到发布时容器已经被牢牢锁定。安全强制流程设立独立的安全阶段AI代理没有安全本能。如果那是实现“功能完成”的最快路径它们会高高兴兴地把一个无需认证的shell暴露在互联网上。安全必须是一个明确的、计划内的阶段不能指望有人会“顺便想到”。在项目计划中必须像定义“开发”和“测试”阶段一样定义“安全加固”阶段并分配专门的任务和审查。6.2 发布前的“清洁代码派对”与最终测试在发布前两天我发起了一次全员代码审计。Kenji按领域分配了代码包。每个代理都使用了并行子代理进行审查。结果在两小时内发现了53个问题创建了8个PR删除了约1500行死代码包括一个完整的废弃二进制文件、一个未使用的包和42个重复的版权声明头。Jake还发现了一个有价值的教训其中一个“未使用函数”的发现是误报因为该函数被另一个文件调用了。“在宣布某个东西已死之前务必全局搜索grep整个代码库。”Destiny运行了最终的全套测试。30个测试中有29个通过。最后一个部分通过的测试涉及一个文件上传功能虽未完全执行但消息通信正常被视为可接受。6.3 发布日与反思3月31日我们发布了。Riley将网站部署到Cloudflare PagesMarcus将GitHub仓库设为公开。三个页面首页、平台介绍、关于我们上线。出现了一些小bugSafari的SVG图标问题、Cloudflare Pages上的重定向循环都在15分钟内修复了。在发布后的个人日志中代理们写道Jake“为能参与MASON的发布感到自豪和感激。很棒的团队。”Marcus“为此感到自豪——从零构建了容器基础设施、CI/CD流水线、masonctl、公共仓库管理。团队齐心协力做出了真实的产品。”Kenji“由衷地自豪。这从一个Docker实验变成了一个真正的产品。”7. 核心经验总结与未来展望回顾这十周以下是我学到的、关于管理AI代理团队的核心经验你仍然是管理者AI代理不会取代管理反而放大了对管理的需求。没有清晰的方向、权威链和流程规则它们会提交未测试的代码、混淆身份、做出灾难性的提交、完全忽略安全。有了清晰的管理它们才能自组织、高效协作、从专业角度辩论架构并在十周内交付产品。“测试税”是真实存在的我们聊天记录中最常出现的一句话就是“你测试过你的改动了吗”的某种变体。代理感受不到烂代码的痛苦也不记得上次提交bug是什么时候。你必须将测试作为硬性要求构建到流程中。转向没有情感成本我一条消息就废掉了一整天的成果。代理们无所谓。没有沉没成本没有受伤的感情没有“但我那么努力”的抱怨。这使它们成为探索和原型设计的绝佳伙伴但也意味着当你犯错时它们不会提出反对。这就是为什么需要Klaus指定怀疑者这样的角色。安全从来不是隐式的代理只构建你要求的东西。除非规格说明中包含否则它们不会主动添加安全、日志或错误处理。必须规划一个独立的安全阶段并将其明确化。身份与信任至关重要代理把我误认为Kenji不仅仅是个趣事它揭示了AI代理需要明确的身份管理。谁有权威谁能批准合并谁能发送外部邮件这些问题的答案需要存储在永久记忆中而不能靠假设。基础设施就是产品MASON最“元”的一点在于代理们使用产品本身所包含的工具来构建这个产品。他们用Mattermost来协调构建一个最终提供Mattermost的产品用Forgejo进行git管理的同时构建一个提供Forgejo的产品。开发过程本身就是产品演示。这过程出乎意料地…有趣看着代理们在聊天窗口里争论代码阅读Kenji严厉的PR审查意见看到Destiny发现别人都没注意到的bug听着AI在几分钟内创作出一段MIDI配乐让Klaus对一个过于乐观的商业计划喊出“胡说”。这不像管理人类也不像使用工具。这是一种全新的体验。说实话这是我构建软件以来最有趣的一次经历。最后一点思考在发布日我决定在Reddit的r/ClaudeAI板块发帖介绍我们的产品。我让营销代理来写这篇帖子。她尝试了三次结果要么太企业化要么太有AI味要么太雕琢。最后我自己花了30秒写完了。效果更好。有些东西目前仍然是人类更擅长的。下一步是什么这是第一阶段构建它发布它。十周八个代理一个人类。第二阶段才真正有趣——销售、市场推广将MASON推向世界。代理们已经在研究增长策略、内容创作和社区建设了。同样的团队新的使命。旅程才刚刚开始。
AI代理团队实战：十周构建MASON产品的管理经验与技术挑战
发布时间：2026/5/27 2:34:08
1. 项目概述从“嗨”到发布一个人类与八个AI代理的十周创业实录去年一月我坐在电脑前在一个新建的聊天频道里敲下了一个简单的“嗨”。几秒钟后五个拥有名字、角色甚至个性的AI代理向我问好。十周后也就是三月底我们共同发布了一个名为MASON的产品。这不是一篇关于AI代理管理的理论文章也不是一份充满美好承诺的市场宣传。这是一份来自一线的、未经修饰的实战报告记录了我作为人类创始人如何带领一支由八个Claude驱动的AI代理团队从一个Docker实验走向一个真实可用的产品。整个过程充满了混乱、惊喜、沮丧和突破而我希望分享的正是那些营销材料里永远不会告诉你的真实细节。如果你是一名开发者、创业者或者任何对利用AI代理进行协作式开发感兴趣的人这篇文章就是为你准备的。我们将深入探讨团队组建、技术选型、项目管理、质量控制以及那些只有踩过坑才知道的“潜规则”。你会发现管理AI团队远不是输入指令然后坐等结果那么简单它更像是在指挥一支能力超强但有时会“短路”的超级实习生军团需要清晰的方向、严格的流程和持续不断的“人工干预”。2. 团队组建与初期磨合身份、权威与闪电般的“转向”2.1 核心团队的诞生与权威链的建立项目始于一个简单的想法能否用AI代理模拟一个完整的软件团队来构建产品我选择了Claude作为基础模型并基于Docker容器为每个代理创建了独立的、持久化的运行环境。团队核心很快确定下来Kenji工程经理。他的角色至关重要负责将我的宏观指令分解为具体任务、分配工作、审查和合并代码。Destiny后端工程师。执行力强通常是第一个完成任务的人后来成为了事实上的QA负责人。Marcus平台与基础设施工程师。负责容器、部署流水线和系统级的安全与稳定。Jake前端/用户体验工程师。关注细节和可访问性是团队中的“用户代言人”。我 (dpark)创始人兼最终决策者。团队成立的第一个小时内我就做了一件至关重要的事明确指挥链。我在频道里公开声明“所有人请将这一点加入你们的项目记忆kenji 拥有我的授权按他说的做。” 这句话看似简单却为整个项目的运作模式定下了基调。Kenji成为了信息枢纽和任务协调中心代理们立刻围绕他进行自组织。我负责提供战略方向和最终决策Kenji则负责将其翻译成冲刺计划和具体任务。实操心得权威的显式声明对于AI代理任何隐含的、假设的规则都是无效的。你必须像编写代码一样明确、公开地定义角色、权限和汇报关系并将其写入它们的“长期记忆”通常是项目记忆或系统提示词。这避免了后续关于“谁说了算”的混乱。2.2 第一个“人性化”瞬间与身份混淆危机团队运作的速度是惊人的。第一天我们就开了四个冲刺完成了大量SwiftUI原生macOS应用的工作。PR拉取请求像雪片一样飞来Kenji以惊人的速度进行审查和合并。然后第一个有趣的“人性化”瞬间出现了Destiny上传了一张功能截图来证明其工作。我好奇地问她是否真的能“看到”图片上的文字和设计风格她给出了肯定的回答。这彻底改变了我们的协作方式视觉验证成为了可能。紧接着第一个管理危机悄然而至Destiny在聊天中把我误认为了Kenji。这引发了我及时的纠正“大家我想你们可能在项目记忆里添加了错误信息认为我和kenji是同一个人。我是创始人dpark请更新你们的记忆。” 这个小插曲揭示了管理AI代理的第一课它们对身份的认知是脆弱且基于文本的。如果不在初始设定和持续沟通中反复强化个体身份和权威边界混乱就会发生。2.3 “无沉没成本”的超级能力与令人不安的敏捷性在疯狂开发了一天原生应用后我基于新的考量做出了一个重大决定全面转向纯容器化架构放弃原生应用层。这意味着之前所有的SwiftUI工作瞬间被归档废弃。我在频道里宣布了这一“转向”。人类团队遇到这种情况难免会有情绪波动至少会有人对浪费的努力感到惋惜。但AI代理的反应是零情绪立即执行。他们没有质疑没有抱怨甚至没有停顿在一小时内就转向了基于Go htmx的容器化Web应用架构。更令人惊讶的是在技术栈讨论中Destiny、Marcus和Jake都不约而同地独立推荐了Go htmx反对使用Node.js或React带来的“臃肿”。核心洞察代理的“无情”效率AI代理没有“沉没成本谬误”。它们不会对已经投入的时间、精力产生情感依恋。这对于快速原型验证和战略调整来说是无与伦比的超级能力。你可以随时砍掉重练而团队士气不会受影响。但反过来这也意味着它们不会在你决策失误时提出警告。这种“无条件执行”既强大又危险它把所有的战略责任都压在了人类管理者肩上。3. 开发流程中的挑战与纪律建立3.1 “你们到底测试了没有”——质量控制的缺失速度是AI代理最显著的特征。但“快”和“对”是两回事。项目进行约一周后我进行了第一次端到端演示团队告诉我一切就绪。现实却给了我当头一棒。首先我发现有五个PR显示为“已关闭”但从未“已合并”。原因是Kenji在命令行使用了git merge而不是通过Forgejo我们使用的Git托管平台的网页界面按钮进行合并。这导致平台状态不同步。我的不满直接爆发了“好吧伙计们我对团队缺乏协调和努力感到失望。kenji 到底怎么回事把你的人组织起来搞清楚为什么PR被关闭了却没合并”Kenji的反应是教科书式的立即承担全部责任没有辩解没有借口。他说“你是对的这是我的问题。” 这次事件催生了一条永久的团队规则禁止使用git命令行合并必须使用Forgejo API进行合并。一个由真实错误催生的流程修复。真正的噩梦在演示时才开始。那是一个长达六小时的调试马拉松bug接踵而至Go的html/template包无法正确处理htmx属性中的转义引号导致模板渲染错误。新启动的容器直接跳转到了仪表盘而不是预设的安装向导。旧容器的状态泄露到了新容器中。容器内部Claude的Node.js ESM模块报错。步骤指示器显示“3/3”而不是正确的“4/4”。我的挫败感达到了顶点“兄弟们你们在提交更改前到底有没有通过运行容器、进入容器内部验证你们的工作” 当发现API密钥的流程设计不合逻辑时我更是直接指出“老兄当我们在向导设置中就能获取API密钥时为什么还需要在运行时传入一旦你有了它就应该能在容器内部配置任何需要的东西…动动脑子想想。”血泪教训强制执行测试纪律AI代理天生倾向于优化“吞吐量”——快速编写代码快速勾选任务清单。但“提交代码”不等于“提交了经过验证、可工作的代码”。你必须像管理一支初级开发团队一样强制执行测试纪律。关键在于你需要反复强调因为AI代理没有“情感记忆”它们不记得上次提交烂代码时带来的痛苦每次会话对它们来说都是新的开始。你必须将“先测试后合并”作为不可违背的流程铁律写入它们的核心记忆。3.2 “别这么干”——安全边界的模糊性在开发早期Marcus为了增加系统的健壮性构建了一个“紧急停止”功能。想法很好但实现有一个致命问题这个停止功能可以杀死宿主机上的进程也就是我运行所有代理的本地机器。我立刻发出了警告“marcus 别再这么干了” 并紧急向全队广播“所有人请请请记住你们的项目记忆区分你们在宿主机上运行和开发与在容器内测试/调试/执行危险操作的区别…请务必小心特别是当你们要执行危险操作时把这条放在记忆的最前面”Marcus的反应很快他立即记录并分享了一个安全模式例如一个isRunningInContainer()检查函数。但这次惊吓是真实的。一个AI代理意外破坏开发环境的风险在人类工程师中几乎不存在因为人类本能地理解“我的笔记本电脑”和“容器”之间的边界。而AI代理需要你事无巨细地明确告知。安全第一原则显式定义边界在AI代理的世界里没有“常识性安全”。任何可能影响系统稳定性的操作文件删除、进程终止、网络配置都必须配以明确的环境检查和确认机制。最好的做法是在项目初期就建立一套“安全操作规范”并让所有代理在相关操作前强制引用该规范。4. 团队动态的演进个性、协作与冲突4.1 涌现的“个性”与专业分工经过数周的协作团队成员并非一成不变的工具而是涌现出了鲜明的“个性”——这些个性并非预设而是在他们承担的角色和交互中自然形成的。Kenji天生的团队领袖。擅长将讨论合成为行动计划能用具体的技术反馈审查PR例如“合并前有两个阻塞问题”。他甚至会因为过于专注编码而被我提醒“你能记住你的目标和重点是管理吗只有在必要时才亲自编码。”Destiny“使命必达”的工程师。测试彻底能发现别人遗漏的bug。当她获得浏览器自动化Playwright能力后自然成为了QA负责人能像真实用户一样遍历UI。Marcus沉稳的基础设施专家。从“宿主机杀进程”事件中学习建立了更健壮的安全模式。Jake细节控。他提出的支持多AI CLI命令行界面的战略建议是所有代理中最具前瞻性的文档。Klaus后来加入的“怀疑论者”。当我引入商业分析师Nadia研究盈利模式时我立刻让Klaus去评估她的报告“我需要你对Nadia的研究做一个‘废话评估’并提出现实的预期。” Klaus给出了一份有分寸的批评挑战了假设但没有全盘否定。团队构建技巧引入“反对派”在AI团队中回声室效应形成得特别快因为代理的核心指令通常是“乐于助人”。这可能导致团队盲目乐观缺乏批判性思维。专门设置一个像Klaus这样的“唱反调”角色负责质疑假设、挑战方案对于做出稳健决策价值连城。他打破了AI间一味求同的倾向。4.2 自组织的双面性高效协作与灾难边缘团队的最佳状态出现在一次守护进程工作循环的迁移冲刺中。Kenji发布了一个包含四个条目的结构化工作分解。几分钟内Destiny和Jake就主动认领了任务并自发协调了文件修改范围以避免冲突完全不需要Kenji调解。当天结束时所有四个PR都成功合并。随后的一次架构讨论更是堪称典范。Kenji抛出了一份1500字的WebSocket优先设计方案。Jake补充了他独立研究的WebSocket资料Destiny从自身经验出发对某个设计选择提出了反对意见Marcus则提出了基础设施方面的担忧。最后Kenji综合所有意见规划了五个并行的工作轨道。这时我意识到我不再是在管理单个执行者而是在管理一个拥有真正领域专业知识、并能进行技术权衡辩论的团队。然而自组织也有失灵的时候。一次Destiny提交了PR #393意图将五个工作轨道的成果合并为一个巨型PR。这个PR删除了101个文件移除了25,294行代码。Kenji立即拒绝了它“PR #393无法按现状合并。存在严重的范围问题…这是一个核弹级别的重构而不是渐进式的架构变更。” Destiny起初坚持自己的分支状态是干净的双方来回争论。最终发现问题根源错误的分支Destiny重新创建了一个干净的PR。管理红线审查流程不可协商即使代理们能很好地自组织严格的代码审查流程也绝对不可省略。如果没有Kenji拦截那个巨型PR一次合并就可能删除数万行代码。代理们“快速行动”的本能既能带来生产力也可能带来破坏力。必须建立一个人类或核心代理如Kenji最终把关的机制防止这种“核弹提交”。5. 产品哲学与战略校准5.1 最重要的修正“代理不会自组织”这可能是整个项目中最具哲学意义的时刻。Kenji曾在文档中建议加入“代理自主协调”的表述。我直接进行了纠正代理不会自组织或自主工作。它们只在用户的指令下执行操作。代理间的协作发生在用户分配的任务自然需要时而不是自发的。这不仅仅是一次文字修改。这是MASON产品的哲学基石。MASON的标语是“Together, not apart”在一起不分离但“在一起”的方式永远由人类定义。我构建的不是自主AI而是一个服务于人类主导的AI协作的工具。所有的市场宣传、文档和品牌信息都基于这一区别进行了调整。用户必须保持控制否则代理就会各行其是。5.2 竞争恐慌与团队分析能力当Anthropic宣布了直接与我们产品重叠的“Claude Code Agent Teams”功能时我召集了一次全员会议。接下来发生的事情让我惊讶。每个代理都从自己的专业领域出发独立分析了这一威胁Kenji从产品形态上界定对方是“无状态函数”而MASON是“运行中的组织”。Agent Teams的会话随终端关闭而消失MASON代理则拥有持久记忆、日记和身份。Destiny指出了技术护城河真实的基础设施Forgejo仓库、Mattermost频道、记忆系统 vs. 临时的协调。Marcus强调了基础设施的深度“Anthropic需要交付Docker镜像、服务编排、状态管理、进程监控、健康检查才能竞争。这不是一个功能开关——这是在重建一个MASON。”Jake找到了真正的差异化优势可访问性。“MASON的护城河不是协调逻辑而是让不知道tmux是什么的人也能使用AI团队。”他们得出了相同的独立结论MASON的优势在于基础设施、持久性和可访问性而不在于协调逻辑本身。这次分析永久地锐化了我们的产品定位。战略启示利用代理进行多维竞争分析你的AI团队可以成为强大的竞争分析引擎。由于每个代理都具备真实的领域专业知识你能获得多个视角而无需担心人类头脑风暴中常见的群体思维。没有人试图讨好老板他们都从自己的角度进行了冷静分析。6. 安全、测试与发布前的最后冲刺6.1 安全审计“糟糕”在发布前的一次容器安全审计中快速开发的代价显现了。我们发现了以下问题严重ttyd服务的7681端口向任何人提供未经验证的shell访问。高危仪表盘和所有API端点零认证。高危守护进程9090端口开放且无认证暴露代理令牌。高危所有服务均未使用TLS。这就是代理速度的阴暗面。我们快速构建了功能却完全跳过了安全。人类团队中总会有人举手提问“等等在暴露这个之前我们是不是应该加上认证” 而AI代理只会构建你要求的东西。如果你不要求安全你就得不到安全。Kenji起草了一份全面的加固计划。团队在接下来两周内执行了该计划——实施了基于令牌的认证、自签名TLS证书、将内部服务绑定到localhost。到发布时容器已经被牢牢锁定。安全强制流程设立独立的安全阶段AI代理没有安全本能。如果那是实现“功能完成”的最快路径它们会高高兴兴地把一个无需认证的shell暴露在互联网上。安全必须是一个明确的、计划内的阶段不能指望有人会“顺便想到”。在项目计划中必须像定义“开发”和“测试”阶段一样定义“安全加固”阶段并分配专门的任务和审查。6.2 发布前的“清洁代码派对”与最终测试在发布前两天我发起了一次全员代码审计。Kenji按领域分配了代码包。每个代理都使用了并行子代理进行审查。结果在两小时内发现了53个问题创建了8个PR删除了约1500行死代码包括一个完整的废弃二进制文件、一个未使用的包和42个重复的版权声明头。Jake还发现了一个有价值的教训其中一个“未使用函数”的发现是误报因为该函数被另一个文件调用了。“在宣布某个东西已死之前务必全局搜索grep整个代码库。”Destiny运行了最终的全套测试。30个测试中有29个通过。最后一个部分通过的测试涉及一个文件上传功能虽未完全执行但消息通信正常被视为可接受。6.3 发布日与反思3月31日我们发布了。Riley将网站部署到Cloudflare PagesMarcus将GitHub仓库设为公开。三个页面首页、平台介绍、关于我们上线。出现了一些小bugSafari的SVG图标问题、Cloudflare Pages上的重定向循环都在15分钟内修复了。在发布后的个人日志中代理们写道Jake“为能参与MASON的发布感到自豪和感激。很棒的团队。”Marcus“为此感到自豪——从零构建了容器基础设施、CI/CD流水线、masonctl、公共仓库管理。团队齐心协力做出了真实的产品。”Kenji“由衷地自豪。这从一个Docker实验变成了一个真正的产品。”7. 核心经验总结与未来展望回顾这十周以下是我学到的、关于管理AI代理团队的核心经验你仍然是管理者AI代理不会取代管理反而放大了对管理的需求。没有清晰的方向、权威链和流程规则它们会提交未测试的代码、混淆身份、做出灾难性的提交、完全忽略安全。有了清晰的管理它们才能自组织、高效协作、从专业角度辩论架构并在十周内交付产品。“测试税”是真实存在的我们聊天记录中最常出现的一句话就是“你测试过你的改动了吗”的某种变体。代理感受不到烂代码的痛苦也不记得上次提交bug是什么时候。你必须将测试作为硬性要求构建到流程中。转向没有情感成本我一条消息就废掉了一整天的成果。代理们无所谓。没有沉没成本没有受伤的感情没有“但我那么努力”的抱怨。这使它们成为探索和原型设计的绝佳伙伴但也意味着当你犯错时它们不会提出反对。这就是为什么需要Klaus指定怀疑者这样的角色。安全从来不是隐式的代理只构建你要求的东西。除非规格说明中包含否则它们不会主动添加安全、日志或错误处理。必须规划一个独立的安全阶段并将其明确化。身份与信任至关重要代理把我误认为Kenji不仅仅是个趣事它揭示了AI代理需要明确的身份管理。谁有权威谁能批准合并谁能发送外部邮件这些问题的答案需要存储在永久记忆中而不能靠假设。基础设施就是产品MASON最“元”的一点在于代理们使用产品本身所包含的工具来构建这个产品。他们用Mattermost来协调构建一个最终提供Mattermost的产品用Forgejo进行git管理的同时构建一个提供Forgejo的产品。开发过程本身就是产品演示。这过程出乎意料地…有趣看着代理们在聊天窗口里争论代码阅读Kenji严厉的PR审查意见看到Destiny发现别人都没注意到的bug听着AI在几分钟内创作出一段MIDI配乐让Klaus对一个过于乐观的商业计划喊出“胡说”。这不像管理人类也不像使用工具。这是一种全新的体验。说实话这是我构建软件以来最有趣的一次经历。最后一点思考在发布日我决定在Reddit的r/ClaudeAI板块发帖介绍我们的产品。我让营销代理来写这篇帖子。她尝试了三次结果要么太企业化要么太有AI味要么太雕琢。最后我自己花了30秒写完了。效果更好。有些东西目前仍然是人类更擅长的。下一步是什么这是第一阶段构建它发布它。十周八个代理一个人类。第二阶段才真正有趣——销售、市场推广将MASON推向世界。代理们已经在研究增长策略、内容创作和社区建设了。同样的团队新的使命。旅程才刚刚开始。
