宝玉提炼 Manus 用 Manus 改造组织的 AI Native 实践要点

推荐阅读：《用 Manus 改造 Manus，AI Native 组织改造的实践和思考》https://t.co/0MEN86K7ow 来自 Manus 很好的 AI Native 组织改造一手实践分享。 基于我的理解提炼一下要点： 【1】团队的工程基建，从对人友好，变成了向 AI 暴露接口 过去我们做工程基建，核心是提升开发者体验，怎么让工程师写代码更爽；但 AI 原生的第一性原理，是如何让 Agent 能接触到真实世界，自己能获得充足的上下文。 比如 Manus 把分散的仓库串成统一入口、让 AI 能在几秒钟内跑通端到端测试、给 AI 权限去读线上日志、看报警、发邮件、控制 Feature Flag，他们做的这些，都是在把整个软件开发生命周期和业务流彻底暴露给 Agent。 人能看到什么、操作什么，Agent 就必须能看到、能操作。当 Agent 能够自己可以验证结果，形成“修改-验证-排查”的闭环时，它才真正从副驾驶变成了司机。 【2】人和 AI 的交互，从过程控制微管理，变成了只给目标，要证据 在传统的模式里，人跟 AI 是结对的方式，AI 写一段人来修改，人还要操心上下文有没有超、代码写得优不优雅，是不是有垃圾代码。但实际上这种过程工程是低效的，就好比你作为一个管理者去微管理你的员工。 - 直接给结果 Manus 工程师把 Slack 里的需求原文一字不改丢给 Agent，老板要什么就告诉 Agent 要什么，不需要告诉 Agent 怎么做，Agent 自己会想办法完成任务。 - 要证据 当人不再一行行看代码时，怎么相信 AI 的结果是否靠谱呢？ Manus 用最好的模型做代码审核机器人，让 AI 自己证明自己做对了。Manus 让 Agent 用测试账号走完注册、支付流程并逐步录屏，产品经理看录屏就能指出哪里不对。 【3】AI 工作流，从人等 Agent，变成 Agent 等人 真正的 AI 原生工作流是高度异步、大规模并发的。如果你只有一个 Agent 在干活，你就得等着它干活，但如果你安排了很多 Agent 同时干活，那么你就不需要等，只需要频繁的在不同的 Agent 之间切换，要么在分配任务，要么验证下结果，效率可以很高。 Manus 的工程师一个人同时开着十几二十个 Session 处理需求；领导层把 20 多个待办丢给一个主控 Session，

来源：X · 宝玉 · x.com