周一早上 9:47，你刚坐下，微信图标就跳个不停。
“上周的周报还没交，行政催了。”
“10 点开会，会议室在 3F，别忘了。”
“上次客户的需求你记了吗？谁负责啊？”
你一边翻上周的聊天记录拼周报，一边往会议室跑。会上七嘴八舌说了半小时，你手抄了半页纸，回到工位却发现——谁该做什么、哪天完成，全散落在不同人的嘴里。
你是不是也想过：要是有个小助手，能自动帮我写周报、记会议要点，再把任务扔到每个人的待办清单里，该多好？
我就是这么想的，然后花两周做出来了。一个很轻量的办公 Agent，不完全聪明，但足够帮我、也帮团队挡住那些重复又碎的事儿。
下面我就把从 0 到 1 的完整过程讲给你听——不堆术语，不装高深，只有踩过的坑和能直接用的思路。
一、先定规矩：这个 Agent 到底做什么？
不要一上来就写代码。我先拿出纸，画了三个圈：
周报生成：根据我这周的聊天记录、代码提交、文档修改，自动草稿一份周报。
会议纪要：把录音转文字，提炼出“结论”和“待办”。
任务分发：把待办自动塞进飞书/钉钉任务，或者发消息提醒相关人。
我给自己定了条铁律：不做一个“万能机器人”。只做这三件事，做好一件再下一件。
很多人的 Agent 最后变成“聊天玩具”，就是因为一开始想解决所有问题。千万别。
二、选什么技术？够用就行
我是 Python 背景，所以选了：
大模型：用 GPT API（或者本地跑个 Qwen 也行，看预算）
框架：LangChain 太重型，我只用 requests + prompt 模板
语音转文字：Whisper（本地或 API）
任务对接：飞书开放 API / 钉钉机器人 Webhook
存储：SQLite + 纯文本文档（前期连数据库都不需要）
整个架构就一句话：触发 → 调模型 → 写结果 → 发出去。
我甚至没用消息队列。因为每天调用量不到 200 次，没必要过度设计。
三、第一步：从“周报 Agent”开始
先说最让我痛苦的场景——每周五下午憋周报。
- 数据从哪儿来？
我写了个简单脚本，去拉三处地方：
会议录音文件（存在本地或云盘）
Git commit log（上周五到今天，我改了哪些代码）
聊天记录导出（企业微信/飞书，手动导出 txt，或直接用 API 拉 mentions）
小坑：最早我想全自动拉所有聊天，结果 API 权限复杂。后来改成：每天下班前手动粘贴重要对话到一个“当日回顾.txt”里。半自动比全自动更可靠。
- 生成周报的 Prompt 长什么样？
我不搞花哨的 chain。核心就是一个 prompt 模板：
你是一个助理，根据以下数据写周报。格式：
【已完成】
【进行中】
【下周计划】
数据：
{会议纪要摘要}
{提交记录}
{聊天重点}
要求：
- 每条不超过一行
- 不要编造没做过的事
- 可以合并同类项
每周末，我把攒的数据塞进 prompt，调一次 API，就出来一份草稿。人工看一眼，改两三个字，3 分钟搞定。
- 没遇到“幻觉”吗？
遇到过。有一次它自动写“已完成用户画像分析”，实际上我只提了一句“下周考虑做”。原因是我在聊天记录里写了“用户画像下周可以看看”，它误判了。
解决办法：在 prompt 里加一句 “只提取已完成的事情，不要推测意图”。同时在数据里用 【已完成】 这种显式标记。教模型格式，比教它理解意思更有效。
四、第二步：会议纪要 Agent，顺便解决“会开了跟没开一样”
场景
周三下午 3 点，需求评审会。产品、设计、前端、后端吵了 45 分钟。散会后，我问每个人“待办记了吗”，三个人的答案都不一样。
做法
录音：用手机或电脑录全程（会前告知团队）。
转文字：Whisper 转成带时间戳的文本。
交给大模型，写两个东西：
结论：大家最后同意了哪几件事？
待办清单：谁、做什么、什么时候完成？
我的 prompt 核心部分：
根据会议转录文本，提取：
- 最终结论（3-5 条）
- 待办事项（格式：负责人 | 任务 | 截止时间）
如果有歧义，标记【未明确】并原样引用原文。
输出示例：
负责人：产品李 | 任务：更新原型灰度方案 | 截止时间：周五
负责人：前端王 | 任务：评估 API 改造工期 | 【未明确】原文：“下周再看看”
踩过最大的坑：“谁”出了问题
模型经常把人名搞错，比如“@老张”在不同人嘴里指代不同。我的解法：
会前在系统里维护一个昵称映射表（老张 → 张伟）
提取待办时要求输出真实姓名 + 部门，不写昵称
如果无法确定，就输出 【待确认】 并发到群里让人点一下
五、第三步：任务分发——把纸上的待办，变成真实的提醒
光有清单没用。我要的是：会刚开完，待办已经出现在每个人的飞书任务中心。
工作流
Agent 生成待办列表（JSON 格式）
通过飞书 API 创建任务（使用 task 或 message with action）
每天 9:30 主动提醒未完成的人
代码核心伪逻辑（非常简单）：
for task in tasks:
assignee = task["owner"]
content = task["content"]
due = task["due"]
feishu.create_task(
user=assignee,
summary=content,
due_time=due
)
这里必须注意：权限不可以给太大
我一开始用的是“超级机器人”令牌，结果它能把所有人的任务删掉。后来改成每个用户的 OAuth 令牌 + 只创建自己权限内的任务。
一句话原则：Agent 能读的信息尽量给，能写的信息不给全。尤其是删除、移交这种操作，一律让人工点一下。
六、完整跑通一次：一个早晨的实战
给你看一个真实的运行日志（简化版）：
8:30 - 触发周报生成（手动命令：/weekly）
→ 读取 5 天 commit + 聊天回顾
→ GPT 输出草稿 → 飞书发给“我”，我改 2 行后发出
9:00 - 会议纪要处理（昨天 16:00 的会）
→ 转文字用时 3 分钟
→ 提取出结论 3 条 + 待办 5 条
→ 发送到项目群：“以下为自动生成的结论与待办，请确认”
→ 群里两人回复“确认”，一人回复“截止时间改到下周”
→ Agent 捕获“改到下周”并更新任务
9:15 - 自动分发任务
→ 5 条待办 → 分别创建飞书任务
→ 任务有延迟提醒（剩余 1 天时催）
整个早上的手工操作从 1.5 小时降到了 15 分钟。最重要的是：没有人再问“我该做什么”。
七、三个最大的坑（希望你不用再踩）
坑 1：模型太自信，把“也许”当“必须”
有一次会议记录里有人说“可能周五看看”，Agent 直接生成了任务“周五前完成评估”。必须加提示词：如果原文有“也许”“可能”“考虑”，一律输出【待讨论】。
坑 2：忘了处理“撤回”和“修改”
有人会后说“那个任务不是给我的”。我的 Agent 最初不会更新。后来加了一个简单机制：任何人在群里回复“任务取消”或“改给@某人”，Agent 监听并执行更改。
坑 3：数据污染
周报生成时，上周的旧数据偶尔混进来。我最后的做法：每次生成单独建一个临时文件夹，只放本周文件，绝不复用历史的缓存。
八、做到什么程度才算“够用”？
我并没有做一个全知全能的 Agent。它只做三件事：
周五下午：帮我写周报草稿
每次会议结束：自动发纪要和待办
每天早上：检查延迟任务并提醒
这已经覆盖了团队 60% 的沟通摩擦。剩下的 40% 依然需要人——比如判断优先级、安抚情绪、拍板决策。
办公 Agent 的意义不是取代人，而是把每个人从“传声筒”和“记事本”角色里解放出来。
九、你也可以从下周开始
如果你也想试着做，我给三个起步建议：
只选一个场景。从周报或会议纪要开始，别贪多。
先跑通手动版本：你复制粘贴聊天记录 → 贴进 ChatGPT → 把输出复制到飞书。跑通这个流程，再写代码自动化。
接受 80 分。它会产生 20% 的错误（比如认错负责人），但只要你设计好“确认”按钮，反而倒逼团队更明确地说“谁做”。
最后说一句：不要追求完美架构。我用的就是 Python 脚本 + cron + 几个 API。两周后它每天都在替我干活，就够了。
那今天下午的例会，你不妨也录个音试试看——也许下周这个时候，你的 Agent 已经帮你写好了这篇技术文章要用的周报素材了。
