据作者现场录音整理，按讲者脉络转述，不是逐字稿。讲者是 Manus AI 的 Agent Engineer Lead，主要做 agent harness 研发。中文演讲，约 22 分钟，无问答环节；中途幻灯片缺了一页，讲者跳过。

一句话

Manus 把全公司的代码、知识、内部系统收进一个 Mono 仓库，让 AI 看全组织上下文；再把每个人的 agent 任务公开，让人也看全上下文；他说 AI 强了以后，瓶颈回到人的决策和注意力上。

论断

1. 端到端开发卡在组织上下文

他引用联合创始人公众号文章开头的场景：现在 Manus 办公室里，研发把产品需求原文一字不动地转给 AI（Manus 或 Codex），由 AI 端到端做完，一个工程师同时接十几二十个这样的需求。早期做不到，缺的是上下文。

“组织内的上下文其实是分散在不同的个人、代码仓库还有内部系统中的”

  • 缺的上下文包括：功能迭代过几次、横跨哪几个仓库、怎么测试、先上哪个服务、同事卡住了怎么办、方案和预期不一样怎么办。
  • 他说时间有限，直接上答案：把上下文、工具和任务都放到所有人看得到的地方。整场围绕 Mono 和任务公开两件事展开。

2. Mono：一个仓库装下全公司

“它里面包含了公司所有的代码仓库、知识库、内部工具，我们一般内部就都叫它Mono”

  • 新人入职只需让 Manus 配好 Mono 就能开发，不论前端、后端、移动端，还是产品、设计。
  • Mono 集成了 debug、查日志、数据分析工具。产品同学发现线上问题先自己在 Mono 里查，简单 bug 自己修，复杂的转给研发，并附上分析、可能原因甚至解决方案。
  • 产品讨论和用户反馈在 Slack，需求文档和 bug 追踪在 Notion，配置 Mono 时顺带配好这两个连接器。流程是研发把 Slack 链接发给 Manus，它读会话、去 Notion 搜文档、读最新代码、开发，上测试环境后回 Slack 频道 @ 产品同学来测。

3. 用统一 Trace ID 让 AI 自己查 bug

他说全链路 OTel 追踪是加速 AI debug 的一个关键。

“AI 可以用同一个 Trace ID，一路查到底，它最后可以直接定位到这个 bug 是由哪个仓库、哪个代码、是谁、在哪一次改动引起的”

  • 用 OTel 定位 bug 通常 20 分钟内完成；紧急线上故障开"极速模式"，5 分钟内完成定位和修复建议。没说以前人工要多久，也没说统计口径。

4. 产品和设计也直接提 PR

以前积压在研发管道里的体验优化、UI 小需求，现在产品和设计自己研发、自己体验、自己上线。他预料到大家会担心产品同学提代码的质量：

“如果他们用的 coding agent 已经是旗舰模型，我们的 code review 系统也是旗舰模型，再加上 Mono 里面有很多的架构设计、研发的准则，其实他们提上的代码质量是完全 OK 的”

  • 最积极的一位产品同学合了 160 多个 PR，没说时间跨度。
  • 语音输入优化：产品同学让 Manus 做原型，测了市面上十几款主流语音模型，选定后又让 Manus 基于前端仓库做了一个交互展示视频发到群里，功能很快上线。
  • 支付系统、付费模块等关键领域，必须对应负责人同意才能合。
  • 他说"目前没有发生过在线上因为代码质量而导致的事故"，没给以前的事故率和观察期。

5. 精简内核加插件，按事分人

为了让更多人参与，技术架构改成精简内核加插件。他说这是一场硬仗，花了相当长时间。好处是内核不变，外围插件功能内聚，AI 开发时更少跨仓库；单点功能故障也不会拖垮整个系统。

“按照事情去分人，而不是按照人去分事情”

  • 一两三个人维护一个大模块，他说"有时候我会感觉自己在维护一个开源项目"。
  • 一位后端同学在他不知道的情况下，端到端做了远程电脑终端控制功能，因为自己要操作家里的电脑工作；功能已上线，一直由这位同学维护。

6. 任务公开：让人也看全上下文

每个人的 agent 任务全公司可见、可加入。起因只是想看同事怎么用 AI、帮用得不对的人改进，做出来后发现一个任务可以多人接力，想知道进展也不用问人。他自己帮同事接力过好几个需求。

“Mono 是解决了 AI 看不全上下文的问题，而任务公开化其实是解决人看不全上下文的问题”

  • 任务常卡在一个技术或产品决策点上。以前要找决策人、交代上下文、讨论完再把结论喂给 AI；现在直接把任务链接发给决策人，他看完可以追问，也可以当场拍板，agent 接着跑。

7. 自动化越多，人的决策越关键

Slack 里有很多基于 Mono 的数字分身。一个分身在每次发版后检查服务健康状态，找到本次发版功能的负责人，@ 他们去线上体验，他说它有一次比公司自己的监控系统更早发现了一个线上故障。

他们还做了自动化接单系统：bot 每天自己去 GitHub 看 issue、写代码、测试、提 PR。几天下来有几十个 PR 没人管、没人审，也不知道优先级。

“如果没有人去定优先级的话， AI 的自动化研发很可能只是在浪费 token 而已”

  • 他说 AI 足够强后瓶颈回到人身上：有产品 sense 的研发写出的功能更好用，懂点代码的产品提的 PR 可能一遍过，需要复合型人才，但怎么识别、怎么分配还在探索。

8. 注意力是不可再生资源

AI 一个决策接一个决策地抛过来，人会看不懂，他认为本质是注意力耗光了。

“现在 AI 时代， Token 是一个可再生资源，而人的注意力变成了一个不可再生资源”

  • 他的做法是不平均分配注意力，把它当投资出去的资产，投到价值和杠杆更高的地方；常规决策沉淀成 skill 和 agent memory。
  • 一位同事一个月花了 10 万美金的 token。复盘发现复杂需求不能让 AI “自动驾驶”，也就是 AI 说什么都回"对，继续"，他自己也这样做过一段时间。现在复杂的事先做方案设计、任务拆分、阶段性验证，目标是质量有保障、工程上不返工。

9. 两个用 Manus 工作的例子

  • 一位 agent 研发同事有一个 Manus 主任务，每天去 Slack、Notion、邮件里找需要他做的事，分成现在就能拍板的、要新建任务的、在等别人输入的三类。他到公司第一件事是问 Manus"我现在要干嘛"，讲者说他的并行度是全公司最高的。
  • 讲者自己：内部权限系统存在很久、很乱，他让 Manus 借 Mono 里对接的内部系统梳理每个人的角色和实际使用情况，找出可以简化的权限，再挨个发 Slack 私信问本人。两天后回收结果，Manus 调整了权限。私信带"from manus"标记，他看回信时发现里面有 30% 也是 Manus 回复的。

存疑

  • 关键领域负责人审批的清单里，“支付系统、付费模块"之后还有一项没听清。
  • 插件"功能内聚"录音里听成"非常内置的”，按语义理解为内聚，需回放。
  • 远程电脑终端控制功能所在的产品名疑为 Manus Studio，未核。
  • 自动化接单系统的灵感来源他说是"Loop Engineering"，是否为准确名称不确定。
  • 20 分钟、5 分钟、160 多个 PR、零代码质量事故、10 万美金 token、30% 代回这些数字都是讲者口述，没给比较对象或统计口径。