上下文主权比功能数量更重要
Mario 对 Cloud Code 的真正不满，不是 UI 抖动或 feature bloat，而是系统提示、工具定义、system reminder 会在版本中不断变化，破坏他已建立的稳定工作流。对于 2026 年的工程师，这意味着 harness 的首要价值是可预测性，不是花哨功能。
AI Engineer 2026 · Video Notes 01
Mario Zechner：为什么 2026 年的 coding agent 必须重新夺回“上下文主权”
把这场 talk 当成 harness 设计宣言来看，它谈的不是 Pi 一个项目，而是 agent 工程里什么该做，什么绝不能做。
这场 talk 最有价值的地方，不是“Pi 很酷”，而是 Mario 把一个常被忽略的核心问题说穿了：如果 agent 的上下文、工具定义和行为边界不归你控制，那么你并不是在使用 agent，你只是在被一个黑盒工作流牵着走。
核心观点提炼
极简核心，外部扩展
Pi 选择很小的 system prompt、少量内建工具、Markdown skills 和 TypeScript extension API。这个方向本质上是在说，agent 应该适应工作流，而不是逼团队适应 harness。
可观测性与可修改性是一等公民
他反复强调 observability 和 hooks 深度。能不能看见 agent 做了什么，能不能在 session 内热重载扩展，决定了团队是“调系统”还是“碰运气”。
反 slop 的根本不是更强模型，而是更窄任务边界
Mario 最后不是在鼓吹全自动，而是在强调任务必须有边界、模块化和可验证目标。agent 适合做 bounded work，不适合在缺上下文时瞎补架构。
站在 2026 AI engineer 的学习点
- 优先设计可控上下文面，而不是继续给 harness 加功能按钮。
- 把扩展机制做成普通工程对象，而不是平台式黑箱插件市场。
- 任何“自动注入更多信息”的功能都要先问，它会不会破坏模型的注意力分配。
- 把 agent 任务限制在上下文闭包内，超过闭包就先补文档、补模块边界、补 eval。
- critical path 代码仍然要逐行读，agent 加速不等于免审。
内容脉络与时间线
Act 1
为什么离开 Cloud Code
从早期惊艳到后期失望，问题集中在上下文被产品方不断改写、缺 observability、缺 model choice。
Middle
为什么 benchmark 反而支持极简 harness
terminal-bench 让他意识到，复杂本地集成不一定比简单 tmux/keystroke harness 更优，关键在控制面和上下文设计。
Design
Pi 的四层结构
provider abstraction、agent core、TUI framework、coding agent 分层，配合 skills 与 extensions，让 agent 可以自我修改。
Act 2
开源维护被 agent 噪音反噬
clankers、低质量 issue、自动化 PR 噪声，把 maintainer 时间从创造性工作拖进了垃圾处理。
Act 3
Slow the f*** down
真正的结论不是“全自动”，而是放慢，把 agent 用在模块化、可验证、非关键的任务上。
值得反复咀嚼的句子
“The real problem is that my context wasn't my context.”
这句几乎可以当作 2026 harness 设计的总纲。
“It's an agent that adapts to your workflow instead of the other way around.”
把“可塑性”抬到比“功能完整性”更高的位置。
“Slow the [ __ ] down.”
反 hype 的一句话，提醒工程师不要让 agent 速度超过自己理解速度。
我的结论
如果 Ryan 代表的是“大规模把 agent 纳入生产系统”，Mario 代表的就是另一条同样重要的线：先把 harness 做成你真正能理解、能修改、能限制的工具。对 2026 年的 AI engineer 来说，这比追最新 benchmark 更重要。