Context Not Control：Netflix 写给员工的话，Agent 先用上了

Manus 团队最近发了一篇《用 Manus 改造 Manus，AI Native 组织改造的实践和思考》。文章里有个画面：工程师电脑上开着一排 Codex 和 Manus 的 Session，点开一个，输入是 Slack 上刚发的需求原文，一字未改。

过去工程师拿到需求，先自己分析，再动手写。现在新需求和新 Bug 基本直接交给 AI。AI 自己去代码里找相关内容，自己改。人亲手执行的部分越来越少，指挥 AI 干活、为结果承担责任的比例越来越高。Manus 团队提到，工程师普遍节奏是一个人在同时处理十几、二十个需求。

马天翼在推文里用一句话概括这种感受：Context Not Control。过去是人指导 AI 干活，用严格限定让 Agent 照葫芦画瓢。模型能力变强后，应该放手让 Agent 探索，避免人的认知限制 Agent。精力应该花在优化 Agent 会用到的研发流程和工具链上，把资料、信息接给 Agent。人主要在关键节点、关键选型、关键约束上提供信息。

有网友在回复里补了出处：Context, not Control 来自 Netflix 文化。字节的组织文化很大程度上参考了 Netflix。马天翼说，自己很早就买过奈飞文化的书，当时看完大为震撼，后来忘了这句话的出处。

Manus 团队做了一个叫 Mono 的代码仓库。代码没有合并到一起。Mono 提供一个统一入口，配上一本给 AI 看的说明书：每个仓库做什么，彼此怎么配合，研发按什么规范工作。AI 要改哪部分，就去拉对应的仓库。

Mono 是一步步长起来的，每一步解决上一步暴露的问题：让 AI 看见全局，补齐独立仓库之外的业务知识，支持跨仓库协作和并行开发；让 AI 在本地验证，过去推到测试环境要等 5 到 10 分钟，现在完整 Manus 跑在本地电脑上，验证只需几秒；让 AI 排查线上问题，在权限控制下读取线上日志、配置和异常记录；让 AI 走完发布流程，审批权仍在人这里；让 AI 完成端到端验证，用测试账号走真实流程，在浏览器和手机模拟器里检查结果。

这套东西带来的变化很具体。Manus 移动端一直只有 7 个人，同时负责 2 个产品、共 4 个移动应用，进度和网页版基本同步。产品经理也能直接改代码。所有产品经理都向 Manus 提交过代码，大约一半能独立完成需求并上线。有人把语音转文字功能从模型选型推进到上线，网页端和桌面端界面都是自己完成的。视频成了新的 PRD，几分钟里交代用户场景、界面设计、点击后的反馈、不同状态和实现逻辑。

市场团队的做法更接近数字同事。合同签署、内部审批完成后，系统发出信号，AI 更新进度，找相关同事推进下一步。这个数字同事会判断 Slack 消息和自己有没有关系，会主动提醒某个项目还在测试阶段，也会跨团队问清楚新功能的适用条件。它用得不顺手时，还能通过反馈接口提需求，自动触发 Manus 的开发任务。

评论区里有人问了一个实际问题：context 谁来养？过期了也没人发现怎么办？这可能是落地时最容易被忽略的部分。写一份上下文不难，难的是持续维护。Manus 的做法是把流程和知识写进 Mono，用的人越多，积累越多。但保鲜仍然是长期问题。

有网友说得直接：指令越细，Agent 越只会照字面执行。上下文够厚，它自己会补颗粒度。还有网友提到，字节有一条管理哲学，提高人才密度，而不是设置复杂规章制度。对应到大模型，就是用高质量模型加更多 context 加更少限制。

很多团队还在把 Agent 当实习生，写一堆细则，生怕它自由发挥。结果人还得补锅。Manus 的实践提供了一个反向样本：把资料、权限、流程接好，让 Agent 自己跑。人的角色没有变小，只是更集中。定义问题，判断质量，决定什么值得做，并为结果负责。

Netflix 那套自由与责任，原本是写给员工的。现在看，Agent 可能比人更早适应。