现场手记 · FIELD NOTES2026.07.25开完会，活已经干完了 · 一次形态迁移
人和 Agent 的协作方式，正在换代——一份飞书 AI 绝活大会的现场手记。
就是这个周末，我在北京参加了飞书 AI 绝活大会。
回来两天了，脑子里还是嗡嗡的。这种感觉很久没有过——不是听了几个新功能发布的那种“哦，不错”，而是隐约意识到自己旁观了一次工作方式的换代，就像多年前第一次看到智能手机的人，说不清楚哪里不对，但知道回不去了。
私心说，我去之前最期待的就是 张Zara（张咋啦）。平时只能隔着屏幕看她的分享，这次终于见到活人了。激动有木有～～她一上台，大屏上打出“如何打造 AI-native 组织”，台下齐刷刷举起一片手机——我也是其中一个。
— Zara 开场：如何打造 AI-native 组织的五个实践
飞书产品经理晶泾上台说她今天什么都没带：“PPT 也没带，我只带了我的 agent。”然后她把 agent 抛进了会议里。
— 晶泾和 Zara 在台上边聊天边让 agent 干活
接下来的十分钟，她和 Zara 就是正常聊天：聊到想招一个 AI native 的运营，两个人你一句我一句把岗位要求说清楚了，顺口喊了一声“你能不能根据刚才我们的描述写份 JD”；聊到会议里经常没人手头有数，顺口问了句“华东地区 7 月销售总额多少”；又顺口说“把全国销售数据做一个 HTML 数据看板吧”。
会还没开完：JD 写好了，数查完了，看板已经上线。最神奇的是大屏上那份 HTML slides——agent 一边听她们俩实时讨论，一边把内容一页页画出来，页面上还挂着一行小字：“内容整理中，讨论展开后会陆续补充结论。”我坐在台下亲眼看着一页 slide 从“先听 TA 讲”变成一整页论点。
— agent 边听边写：为什么需要团队级别的 Agent
演示的收尾，晶泾说“你讲了这么久，我请你喝杯咖啡吧”，然后对 agent 说：帮她买一杯抹茶拿铁，送到北京的融中心 A 座。
这篇文章想把那天下午我看到的东西讲给没去现场的你——以及，讲完之后，说说我坐在台下没忍住的两个追问。
会议的三个 Level
THREE LEVELS OF MEETINGS
在晶泾 demo 之前，Zara 先给了一个框架。她平时在湾区，最近密集地跟创业者、CEO 和开发者聊“怎么进化成 AI native 的组织”，这场分享是她的阶段性答案。
她说，人和 AI 围绕会议的协同，有三个 Level：
Level 1 · AI 是书记员
开完会后 AI 总结纪要和待办，人去处理待办——这是今天大多数人所在的位置，用妙记、用智能纪要，AI 是个书记员。
Level 2 · agent 直接把活办了
开完会后 agent 不仅总结纪要，还自己直接把待办办了。销售开完会，CRM 自动更新了；产研开完会，任务自动布置下去了，甚至 bug 就直接修了。会议成了驱动 agent 主动工作的 prompt。
Level 3 · 边聊边干
agent 直接加入会议，你边聊它边干，会还没开完，待办已经办完了。这就是晶泾现场演示的东西。
— 会议三 Level：从 AI 记纪要，到 agent 边聊边干
压缩沟通和执行之间的距离。 以前我们默认开会是沟通、执行在会后；但如果这个距离可以压缩到零——沟通即执行——那很多“结论是再约一个会”的会，根本不需要存在。
她还给了一个更大的坐标系：工作方式的三次演化。打字式工作（在电脑前敲键盘），到口喷式工作（现场让用语音输入法的人举手，将近一半），再到聊天式工作——你和同事聊天，agent 在旁边听着，现场就把活干了。一次比一次更接近人类最自然的沟通方式。
“开会是未来的 prompt”
MEETING AS PROMPT
这场分享里我认为最值得记住的概念，是 Zara 提的 agent readable。
她的逻辑链是这样的：今天的模型已经足够强，如果你的 agent 表现不好，“大概率不是它的问题，是你的问题”——不是智能问题，是 context 问题。所以 AI native 组织的另一个说法就是 agent readable 组织：你企业里的沟通、会议、文档、决策过程，对 agent 是不是可见的？
聊天记录是一种 prompt——把 agent 拉进群里，大家在群里聊方案，聊天记录就是它的 PRD。会议逐字稿是一种 prompt——“绝大部分企业没有书面沟通的文化，大部分人不擅长写文档，但说话的能力人人都有”，所以只要不是超级敏感的会，都录下来，录音不是给人看的，是给 agent 的 context。甚至日历也是一种 prompt——agent 看到你明天有客户拜访日程，主动去 CRM 查客户信息，把方案和会前材料准备好，你一个字的 prompt 都没写。
prompt engineering 作为一项独立技能，正在消解。 你不需要学会写完美的提示词，你只需要让你的工作痕迹对 agent 可见。
从个人助理到“同事”：团队 agent
TEAM-LEVEL AGENT
Zara 讲的另一个趋势，是最 AI native 的公司里，agent 已经不是个人助理，而是团队级别的、共享的 agent——它有团队级别的 context，像一个同事。
她给了企业用 AI 的三个段位：Level 1，人跟人协作，没有 AI；Level 2，每个人跟自己的 AI 协作（大部分人在这一层，而且人与人的协作在飞书上、人与 AI 的协作在本地工具里，两者是割裂的）；Level 3，AI 无缝融入人与人的协作。
团队 agent 能做到什么个人 agent 做不到的事？她列了五条：工作可以接力（agent 拉了个数，数据分析师发现口径不对，直接在群里回复纠偏）；它是一种潜移默化的 AI 培训（你看到同事怎么跟 agent 互动，“哦，还能这么用”）；它能参与 brainstorm（你和同事的讨论痕迹，本身就是你们一起为 agent 创作的 prompt）；它有全局视角（有的团队周报已经完全是 agent 写的）；它能服务上下游团队（组织的低效往往不来自个人，而来自团队间的依赖）。
她引用了 Shopify 的实践：几千人的公司，内部 agent 只在群聊里工作、不跟人私聊，结果所有人都在向所有人学习怎么用 AI——不需要课程表和培训计划的“渗透式学习”。
有意思的是，“为什么需要团队级别的 agent”这个论证本身，就是那场 demo 里 agent 边听边写出来的。晶泾还现场讲了她们团队自己的团队型 agent——内部管它叫“CC 王”，进所有项目群、所有会议，研发说好的上线忘了同步，它会在群里 @人追问进度。
— agent 实时总结的团队 agent 三大价值，下方是“CC 王”案例
落地方式她们也当场给了两条：飞书 AI 里新上线的“团队智能伙伴”，或者直接连一个 Claude Code / Codex 的 agent 进来，拉到群里给它团队级别的 context。
另一个方向的进化：对话框不是终态
BEYOND THE CHATBOX
同一天下午，自媒体博主大师的分享，从另一个完全不同的角度撞上了同一个问题。
他的开场白是：“我已经不太通过 Codex 的对话，来管理整个开发流程了。”
他的痛点每个重度用户都懂：对话越积越多，你想对某个功能做二次修改，根本找不到当时是在哪个对话里做的；agent 又会自己唤起新对话，上下文被海量噪声淹没。他的类比很妙——没有人会在 100 人大群里讨论技术细节，PMO 会逼你拉专项小群。
所以他给自己的 Codex 做了一个任务看板：积压事项、待办、进行中、审核中。他不再开对话，而是往待办里加任务，Codex 定时来“捞”任务去做，做完放进审核区等他验收。每条任务聚合了所有相关讨论和修改记录，跨越多个对话，按功能维度回溯上下文。没想清楚的想法放进积压区——“为那些还没想清楚的事情，留一个位置”。
更进一步，他把这套流程从写代码泛化到了自媒体选题调研，并且提出了一个我认为全场最工程化的原则：一个可持续运行的 agent 工作流，必须设置“无人参与时”的降级方案。如果 loop 能不能转起来取决于你有没有及时喂选题，它一定会死。所以他让 Codex 每周日晚自动收集他本周在各平台点赞收藏过的内容作为选题来源——点赞收藏是他本来每天就要做的事，人的参与成本被压到无限低。“不要高估人的判断和审核能力。”甚至同事的点赞收藏，也通过多维表格同步进了同一套流程。
— 大师的选题调研 Loop：从被动接收到主动获取
两个人从相反的方向，抵达了同一个判断——对话框不是人机协作的终态。 Zara 的方向是让 agent 融入人与人的协作现场（会议、群聊），大师的方向是给人和 agent 建一个共享工作空间（任务看板）。
共同点是：协作的载体从“一问一答”变成了“共享的状态”。
以上是我听到的。接下来是我不完全同意的——或者说，是这场大会没有讲、但我认为更关键的部分。
追问一：readable 和 actionable 之间，隔着一条鸿沟
回看晶泾那场惊艳的 demo：写 JD 是生成，查销售数据是读取，做 HTML 看板是生成，买咖啡是调一个外部 API。全部是“读 + 生成”型任务。而 Zara 口头描述的更性感的场景——agent 自动更新 CRM、自动修 bug、自动推进项目——是写入第三方系统、修改生产代码、推动人去执行，是要承担后果的 actionable 任务。demo 里一个都没有出现。
这不是挑剔。让 agent“读到信息”是低门槛的，飞书开放 API 就有；让 agent“写入系统并承担后果”才是真门槛——它涉及权限设计、责任归属、跨系统打通、出错回滚。Zara 自己也说了一句“背后要做很多权限设计、知识库设计、memory context 优化”，但一带而过。恰恰这一带而过的部分，才是企业真正要翻的山。评估一个组织的 AI 化程度，不要看 agent 能读到多少，要看它能写入多少系统、出错时谁负责。
“给团队配一个共享 agent”听起来是个技术决策，其实是个组织设计决策。如果你按岗位切——HR agent、销售 agent、财务 agent——你只是把人类的部门墙原样搬进了 AI，agent 也会有“这不归我管”。而 AI 的本质优势恰恰是没有人类的能力边界：一个 agent 完全可以既懂产品又懂销售、跟着一条业务流从获客走到续约。
按岗位切分 agent，等于用 AI 固化旧组织的 bug；按业务流切分，才是释放 AI 的无边界优势。agent 架构是组织架构的镜像——它的设计实质上是组织的再设计，这是治理问题，不是技术选型问题。下次有人给你展示“我们建了三个部门 agent”，你可以问一句：为什么不是按客户旅程建？
会散场的时候，我想起 Zara 描绘的那个画面：未来的工作方式，也许是找一个舒服的地方，喝着咖啡聊着天，让想法碰撞出火花，剩下的交给 agent。
那杯抹茶拿铁大概真的会送到。但在它送到之前，每个组织都得先回答那两个更难的问题：你敢让 agent 写入哪些系统？你的 agent，是按部门墙切的，还是按价值流切的？
CLOSING · 收束
答案不同的公司，五年后不会在同一个位置。
— Zara 的收尾页：实践是打造 AI-native 组织的唯一方法（系列第二篇，我们去看光谱的另一端：一个安徽芜湖的厂二代，在连质量工程师都招不到的工厂里做全厂唯一的 FDE。）
我是杰西卡，为你精读海内外一线 AI builder 的一手观察与干货。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。
THANKS FOR READING
