深度拆解 | FDE小团队是如何搭建项目管理Agent的？

作为 FDE，项目管理是一定绕不开的难题。最近我们刚刚在飞书跑通了一个叫“马斯克”的项目管理 Agent 工作流，速度来跟大伙拆开复盘下～

传统项目管理工具建了一堆，最后全死于“维护成本太高”。复盘下来，真正卡死小团队的就这 5 个摩擦点：

我们搭建的项目经理Agent，是为了把散落在沟通里的信息自动整理成可以持续追踪的项目记录，同时给轻量任务提供一个统一、低摩擦的入口。项目是否应该继续，仍然由人判断。

现在，这套流程已经能够完成一条相对完整的链路：

沟通自动录音→ 音频转写→ 项目信息纠错→ 识别说话人→ 拆分不同项目→ 提取进展与待办→ 写入统一飞书多维表格项目表→ 设置提醒→ 判断任务类型→ 分派给专业 Agent→ 回收执行结果→ 更新项目状态→ 暂停或结项归档

这篇文章就把这套流程从头到尾拆开。

一、第一步：把沟通完整留下来

项目管理 Agent 要整理项目，前提是它能拿到项目沟通。

我们的入口来自安卓手机自带的通话自动录音。（苹果手机目前不行，可考虑用录音卡之类的替代）

不管是电话，还是微信语音、飞书、钉钉等沟通，都可以根据手机支持的范围配置自动录音。

录音结束以后，手机会生成一个音频文件。文件名里通常会带上日期、沟通平台和对方昵称，格式则是 MP3 或其他常见音频格式。

这个文件名方便人查找，也给了Agent三个重要的上下文：

有了这些信息，Agent 后面才有机会把说话人和已有联系人对应起来。如果没有自动录音，很多项目变化只能依靠人会后回忆。

人对一场谈话的印象通常是“我们大概谈了什么”，但项目管理需要的是更具体的信息：谁答应了什么，什么时候完成，哪个项目暂停，哪项资料还缺。

这些细节一旦没有被记录，后面再聪明的 Agent 也无法还原。

所以第一步是完整保留真实发生过的沟通，再进行自动整理。

二、第一遍转写只负责声音变文字

音频生成以后，我们会把它直接发送给飞书上我们自己搭建的项目经理 Agent-马斯克。

马斯克Agent收到音频，先调用支持音频处理的模型，把录音转成文字。如果录音里有两个人，第一遍通常会先标记成“说话人1”和“说话人2”。

这一步只完成最基础的转换：

音频→ 带时间顺序的文字→ 初步区分不同说话人

第一遍转写不会直接进入正式项目记录。因为通用模型虽然能够识别大部分日常语言，却不一定认识公司内部的专有信息。

客户姓名、项目名称、产品名称、内部简称，如果发音相近，很容易被转成另一个看起来合理的词。

如果把这份原始转写直接交给另一个模型总结，错误会继续向后传播。

一个客户名字写错了，Agent 可能找不到对应联系人；

一个项目名字写错了，进展可能进入错误的项目；

一个产品名写错了，后续检索也会失去准确性。

因此，第一遍转写出来的文字不能直接用，必须先经过一道专门的专有名词纠错层，再进行下游总结。

三、项目经理 Agent 为什么能改对专有名词

通用语音模型打错了字，Agent 凭什么能把它改对？它并不是在凭空瞎猜。

通用 ASR（语音识别）在遇到没见过的生僻词时，通常只会按照相近拼音强行转录出一个错别字或日常词汇。

而项目经理 Agent 纠错的底层机制，是把这份带着候选错词的原始文本，与飞书多维表格里的“实体字典”（客户名单、项目台账、产品线代号）做了一次基于上下文的语义对齐与模糊校准。

第一遍转写完成以后，马斯克 Agent 会带着这些已有的项目档案，把文本重新审视一遍：

项目上下文与实体字典，直接大幅收窄了解题空间。

同一个发音，在全网公开语料里可能有几十种合理的汉字组合；但一旦约束进具体团队的业务范围，它往往唯一对应某个真实存在的客户或项目。

项目经理 Agent 的本质，是先用通用模型“听个大概”，再用多维表格里的实体底表“查字典校验”。

这也是为什么纯转写工具和接入了业务数据库的 Agent 在可用性上天差地别：前者只理解大众普通话，而后者知道你库里存了谁、正在推进什么。

四、说话人识别：先用上下文，必要时再用声纹

文字纠错以后，还要把“说话人1、说话人2”替换成真正的身份。

我们的多数场景是两个人对话。

只要确认其中一个人是谁，另一个人通常就可以根据文件名里的联系人信息确定。

目前有两种识别办法。

第一种是根据内容和角色判断。

项目经理 Agent马斯克已经知道联系人在项目中的角色。

例如，有人主要负责客户接洽和需求沟通，另一个人主要负责技术方案。对话中经常谈商务和需求的一方，与经常回答技术问题的一方，在内容上会表现出明显差异。

再结合录音文件名里的联系人，马斯克Agent 通常可以判断两名说话人分别是谁。

这种方法的优点是简单，不需要额外处理声音。

但它也有边界。

如果两个人谈论的内容非常接近，或者录音里不止两个人，只靠语义可能无法稳定区分。

这时可以使用第二种方式：比对声音音色（听声辨人）。

提前录制一段指定文字，让系统提取本人声音的声纹特征。处理新录音时，再从不同说话人的片段中截取声音，与已有声音进行匹配。

匹配成功以后，系统就能确认哪一个说话人是本人，剩余说话人再结合文件名和项目联系人识别。

简单场景先用文件名、联系人角色和对话内容判断；内容无法判断或进入多人场景时，再用声音补充。

五、一次谈三个项目，Agent 要先拆开再归档

真实沟通很少按照项目管理工具的结构进行。

人不会在电话里说：“现在结束项目A，下面正式进入项目B。”

大家可能先聊一个客户的资料，顺便提到另一个项目的进度，最后又安排一件和第三个项目有关的任务。

如果Agent只把整段谈话总结成一条记录，这条记录就很难继续使用。

项目A的进展、项目B的风险和项目C的待办被塞在同一段文字里，后面既无法准确提醒，也无法在查看单个项目时得到完整状态。

所以，说话人确认以后，项目经理Agent还要判断谈话中涉及了哪些项目。

如果一次沟通涉及多个项目，就按照项目信息分别拆开：

一段完整谈话

├── 项目A：新增进展、待办

├── 项目B：状态变化

└── 项目C：需要补充的资料

拆分完成以后，再把每一部分写入对应项目。

这一步很重要。

录音和转写只是沟通记录，按项目拆分以后，信息才真正进入项目管理系统。

六、统一项目表：项目状态的唯一法定落点（含暂停与结项）

拆出的项目进展和待办，最后会进入一张统一的飞书多维表格。

这张表存储项目和客户等核心字段，是项目经理 Agent 查询和写入状态的固定唯一入口。

很多团队用 AI 做项目管理，往往只设计了“创建任务”和“提醒任务”，却忽视了一个关键现实：项目不会永远按计划跑，它会暂停、调整，甚至被取消。

我们曾踩过一个极典型的坑：一个原本推进的项目中途决定暂停，但这个决定只停留在某次群聊或电话里，没有结构化地写进项目表。几天后再跟 AI 讨论工作，它依然把该项目当成“进行中”，追着人要进度。

从人的直觉看，会觉得“AI 记性太差或者幻觉了”。但从第一性原理看，这是上下文与系统状态的混淆：

现实世界里的项目状态变化，不能靠给模型“增加上下文”来解决，必须有一套法定落点。

在真实业务中，项目绝不仅有“进行中”和“已完成”两种状态。它可能尚未启动，可能处于搁置，也可能在复盘后正式终止。一个完整的项目生命周期，必须在表格中留下明确的闭环定义：

“聊天负责产生信息，表格负责确认现在。”

这是整套系统最核心的运行法则。

Agent 每次执行动作或回答问题前，优先读取的是多维表格里的法定状态：看到“暂停”，就停止追问；看到“已结项”，就归档锁定。

只有让状态在表格里真正闭环，项目管理才算从混乱的聊天流，落成了靠谱的确定性系统。

七、项目经理Agent负责判断和分派任务

项目沟通里除了进展和提醒，还会产生可以直接执行的任务。

例如，一个项目需要采集一些资料，或者整理一批数据。这时可以直接把需求发给项目经理Agent。

它首先把任务写进任务列表，然后判断下一步怎么处理。

技术Agent完成以后，把结果回传给项目经理Agent。

项目经理Agent再向人反馈结果，并更新任务列表中的状态。

链路是这样的：

人提出任务→ 项目经理Agent登记任务→ 判断任务类型→ 自己执行，或分派给技术Agent→ 技术Agent回传结果→ 项目经理Agent反馈给人→ 更新任务状态

这样做的好处是，人不需要记住每件事应该去找哪个Agent。只需要对着一个统一入口说话。项目经理 Agent 负责调度、转交和收回结果，而不是由人去充当“数据搬运工”。

这套分派体系真正帮团队降低的，是人的启动成本。

以前处理一件轻量级任务，要坐回电脑前、打开软件、远程连接开发环境、再去翻找对应项目目录。

真正执行可能只要几分钟，前面的操作准备却很费劲，启动成本极高，容易让人拖延甚至搁置。

现在所有项目动作都收敛到飞书上的马斯克 Agent。

人用手机在飞书随时发一句话，后面的项目定位、任务分派、结果回收和状态更新全由它自动跑完。它最大的价值，就是把高摩擦的多工具切换，压缩成了极低门槛的单点交互。

八、边界约束：目前能稳定分派的，还是短平快任务

这套Agent分派流程虽然已经能够跑通，但边界同样很清楚。

目前适合交给技术Agent的，主要是资料采集、数据整理等相对轻量的任务。

它们有几个共同特点：

还做不到把一个长流程、复杂开发项目完整交给Agent，然后等它自己做完。

长任务会遇到更多问题：上下文如何持续、过程发生变化怎么办、中间结果由谁检查、判断错误由谁负责。

依靠Agent无人运行，这部分我们暂时还没实现。

当前更实际的价值，是把那些原本需要人打开多个工具才能完成的简单技术任务，缩短成一次对话。

九、便利性的代价是Token

过去由人完成的动作，现在需要Agent读取信息、查找项目、调用模型、分派任务和整理结果。

这些动作会消耗Token。

以前是人脑记住应该打开哪个软件、进入哪个项目、把什么信息复制到哪里。现在这部分操作被转移给Agent，人的时间和注意力被省下来，模型调用成本则会上升。

这套系统把成本从人的操作摩擦，转移成模型和Agent的运行成本。

是否值得，要看省下来的时间和遗漏风险，是否高于Token消耗。

我们现在主要调用 Gemini 模型。现阶段的模型开销远低于人工折腾的时间成本，极低的 Token 预算就足够支撑全天的高频调用。

对于偶尔发生的一次性任务，手工操作可能更简单。

对于每天都在发生、需要跨多个项目整理的沟通，把这些步骤交给Agent更有价值。

使用这套系统时，需要算清楚这笔账。

十、项目很多以后，不需要每次把整张表喂给模型

项目表越来越大以后，Agent每次读取可能会消耗大量Token。

实际查询不需要每次扫描全部内容。

当人询问某个项目时，Agent可以先根据项目名称、客户、联系人等关键词定位相关记录，再读取命中的内容。

它的工作方式更接近：

搜索用户提到的一个项目→ 提取项目关键词→ 在统一项目表中检索→ 找到对应项目→ 读取最新状态和相关任务→ 基于当前记录回答

即使项目表达到一万行，只要项目名称和基本信息能够被检索，Agent也只需读取命中的记录。

十一、最小可用版本，不需要一开始就把所有功能做完

如果现在从零搭建，不需要第一天就加入声纹、多Agent和复杂结项审批。

可以先跑通最短的一条链路：

发送一段项目录音→ 转成文字→ 人工确认说话人→ 提取项目进展和待办→ 人工确认归属→ 写入统一项目表→ 到期提醒

只要这条链路能够稳定工作，项目沟通就开始从聊天进入可管理的记录。

之后再逐步增加：

搭建顺序应该跟真实问题走。

不需要为了看起来像一个完整Agent系统，把所有功能同时堆上去。

最后：项目经理Agent的核心是持续更新项目状态

音频转写、专有名词纠错、声纹识别和多Agent分派，解决的是信息怎样进入系统、任务怎样被执行。

真正让它成为“项目经理”的，是每个项目都有明确的当前状态，下一步有人负责，到时间能够提醒，停止时也能正式结束。

项目管理需要一份持续更新、随时可查，并且记录项目开始和结束的正式记录。

做 Agent 系统最忌讳自嗨式的功能堆砌：把输入摩擦降到最低，把状态唯一钉死在表里，人才能真正从繁杂的流程工具里抽身，专注在业务判断本身。