你有没有遇到过这种情况——团队里每个人都在推进方向也都没错但系统却越来越像一堆散件而不是一台机器。这是企业级 AI 项目最典型的死法之一。今天我们开了一场会专门聊怎么防止这件事发生。不是因为出了什么惊天动地的新功能而是因为我们越来越清楚一个企业级 AI 项目难的从来不只是把功能做出来而是让人、流程、知识和 Agent在同一套系统里协调地往前走。今天会上聊了文档、协作、多 Agent、上下文、测试、提交流程。看起来分散但把它们放在一起其实都在回答同一个问题企业级 AI到底怎么从“能跑”走向“可持续”。一、当团队开始认真整理文档系统才算真正进入工程阶段这两天团队把docs目录重新整理了一轮。表面上看只是文档结构更清楚了。但如果你做过稍微复杂一点的项目就会知道一个团队开始认真对待文档往往说明它已经不满足于“先跑起来”而是开始考虑以后怎么持续演进。这次整理里有两个东西特别关键。1协作待办从 Bug 流程里独立出来了Bug 还是 Bug修复、验证按流程闭环。但那些长期推进的需求、模块任务、协作事项不再混在缺陷列表里而是有了单独的协作待办分成四种状态认领中已完成已取消阻塞中这件事看似基础其实很重要。多人协作系统最容易出现的问题不是没人做事而是每个人都在做事却没人知道别人做到哪一步了。更重要的是这份待办不只是给人看的也是给 AI 看的。谁认领了、谁在做、谁阻塞了——这些状态一旦清楚AI 就知道哪些任务被锁定、哪些模块正在推进、哪些地方不该重复介入。文档不再只是“记录”而开始参与协作本身。2ADR 被引入了记录的不只是“现在是什么”还有“为什么会这样”ADR全称Architecture Decision Record架构决策记录。它的意义不在于把事情写得更正式而在于——给系统留下演化记忆。任何一个复杂系统当你问它“你为什么会变成这样”最可怕的答案不是“有 bug”而是“不知道反正就变成这样了。”ADR 就是在对抗这件事。当初为什么这么设计这个选择替代了什么这个变化是临时方案还是长期方向这些问题ADR 都在留答案。很多系统最后变乱不是因为没人写代码而是因为没人持续记录我们为什么会走到这里。而在 AI 参与越来越深的情况下这件事比以前更重要。因为文档不仅是给人看的它也是 AI 能不能理解系统、跟上系统的前提。二、多 Agent 协作我们没有急着押宝而是让三条路同时接受检验今天信息量最大的一块是多 Agent 协作。目前团队同时在跑三种模式而且都已经进入集成测试阶段。很多人在做多 Agent 时第一反应是“到底哪种模式最好”但真实工程里这个问题往往没有标准答案。不同任务对协作方式的要求本来就不一样。所以我们没有先押宝某一种而是让三条路同时跑让真实任务场景来给出反馈。第一条交叉验证模式每个 Agent 都拿到完整上下文从不同角度独立思考再互相验证结论。它强调的不是分工而是多视角校验。适合那些结论质量要求高、不能太依赖单一路径判断的任务。第二条多 Teams 模式任务先拆分交给不同 Team 或子 Agent 分别推进Team 内部再做循环校验。它更像标准工程分工边界明确效率优先适合可拆解、可并行的任务第三条黑板模式每个 Agent 先做自己的部分再把结果汇总到一块“黑板”上由 Leader Agent 统一审阅和收敛输出。它更像现实世界的项目组协作先分头做最后集中拍板这三条路线背后对应的是三种协作哲学多视角碰撞并行分工推进中心角色收敛哪条最终更优今天还没有结论。但有一件事已经越来越明确多 Agent 的难点不在于把 Agent 变多而在于让它们形成有效协作。演示系统喜欢展示“我能调起几个 Agent”真正要落地的系统更在意的是这些 Agent 到底怎么分工怎么校验怎么收敛最后能不能稳定地产出结果这就是企业级 AI 和演示型 AI 的区别之一。三、一个“上下文小问题”背后是企业 AI 的核心命题今天还有一个讨论越聊越大。起点只是个看起来不大的问题当用户进入飞书和 AI 对话时系统能不能知道这个人是谁、在组织里是什么角色、和其他人是什么关系目前这件事还没完全做好。于是问题来了要不要把组织架构直接注入上下文让 AI 一进来就“认人”这个想法听起来很顺。但只要继续往下问两句就会碰到真正的难点如果组织有几百人是否值得每次全量注入如果不全量注入应该在什么时候触发召回如果要召回要不要先做意图识别你会发现一个“把用户身份带进去”的小问题往下拆已经连到了三件事上下文管理记忆召回意图识别而这三件事恰恰构成了企业级 AI 体验最关键的一条链路。很多人把注意力放在“模型回得好不好”但越往后做越会发现真正决定体验上限的往往不是模型说了什么而是在它开口之前系统到底给了它怎样的上下文。模型只是最后负责表达。真正决定智能边界的是上下文组织能力。四、那些“不性感”的工程细节反而最决定系统能不能跑稳今天会里还有一部分内容很日常但我反而觉得特别重要。比如提交节奏先本地验证再推代码先独立提交再集中同步。有人已经在多个 Worktree 上并行开发每条线各自推进、各自测试最后统一合并。这其实是在速度和秩序之间寻找一个现实可行的平衡点。再比如测试环境。自动化流水线还不够完善部分流程仍依赖手动打包。短期看只是“麻烦”长期看它会直接决定团队的验证效率和协作质量。还有一个细节有成员开始各自申请自己的飞书机器人在本地直接验证功能而不是被动等测试环境发版。这些事情单独看都不大。但真正做项目的人都知道决定一个系统能不能长期稳定演进的往往不是最耀眼的新功能而是这些最容易被忽视的工程纪律。因为系统一旦复杂起来真正拖垮迭代速度的通常不是“不会做”而是明明做了却总是接不上、测不稳、收不拢。五、项目做到这一步协作本身已经成了核心能力今天会上另一个感受也很强每个人都在往前推而且推的方向都不一样。有人在做多 Agent 协作有人在补上下文工程有人在写知识图谱和 Wiki 页面有人在做测试集和接口测试也有人在整理文档、补护栏、补规范。项目是活的而且活得很快。但项目越快另一个问题就越突出信息扩散的速度已经开始比代码提交的速度更快。你这边刚改了某个 session 的逻辑另一边可能还在基于旧假设设计 Agent你这边刚对知识库做了兼容降级另一边可能还默认它一定存在。所以今天最重要的不是哪一个功能又多做完了一截而是大家越来越主动地说清楚我在做什么现在做到哪一步接下来可能影响哪里哪些地方别人先别碰这件事在传统研发里叫“协同”在 AI 深度参与研发之后它已经更像一种核心工程能力。因为当参与者除了人还包括 AI 和 Agent 时“说清楚”本身就是生产力的一部分。六、第十天我们还没有答案但已经开始长出方法十天前我们还在讨论这个项目到底要做成什么样。十天后很多东西都变了——我们开始并行测试不同的 Agent 协作模式开始认真搭文档体系开始讨论上下文、记忆、检索之间怎么协同开始给测试和提交补纪律也开始意识到真正难的不是功能本身而是系统如何在持续变化中保持一致性。项目当然还没有完成。很多机制还在搭很多问题还没彻底解决新的麻烦也一定还会继续冒出来。但有一件事已经越来越清楚一个企业级 AI 系统的成熟不会因为某个瞬间突然到来。它是在每天多讲清楚一件事、多补完整一条规则、多做顺一次协作的过程中慢慢长出来的。这是第十天。不是一个阶段的结束而是一个系统开始真正长出“方法”和“秩序”的时刻。《从0到1企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话只记录进化。如果你也在做企业 AI 落地欢迎留言来聊。或者把这篇转发给一个正在踩同样坑的朋友。