Amp 官方刚发了一篇 blog：Amp, Rebuilt，正式公布了新 CLI 的第一块更新，代号 Neo。
表面上看，这是一次 CLI 重写。
但我觉得更值得看的，是它背后的判断：AI 编程工具正在从“你坐在终端旁边一点点指挥它”，变成“你给它更长的绳子，让它自己跑得更久，然后你在关键时刻远程介入”。
这其实是一个很大的变化。
以前我们用 coding agent，经常像带实习生。
它跑一步，你看一步；它要执行命令，你点一下；上下文快满了，你赶紧 handoff；它正在干活，你又想补一句话，结果不知道该打断还是等它结束。
Amp 这次重写 Neo，基本就是围绕这些痛点来的。
为什么先重写 CLI？
Amp 在原文里说，他们之前已经写过一篇《The Coding Agent is Dead》，核心判断是：未来的 agent 会有更长的 leash，也就是更长的自主工作半径。
它不应该只待在一个终端里。
你应该可以从任何地方启动 agent，让它在不同地方运行。比如网页、终端、远程环境、后台任务，甚至未来更多入口。
但 Amp 也承认，终端仍然重要。
因为很多开发者还是想让 agent 就在自己旁边。你在项目里改代码、跑测试、看 diff，这些事情终端依然是最直接的地方。
所以他们先重写 CLI。
新的 CLI 还是 Amp in terminal，但底层架构已经换了：可以远程控制，优先考虑上下文压缩，支持插件，而且速度更快。
远程控制：终端里的 Agent，也能从网页接管
Neo 的第一个变化，是 remote control。
你在新的 Amp CLI 里启动一个 thread 之后，可以从 ampcode.com 远程控制它。
不是只能看状态，而是可以真的发消息、排队、取消当前任务。
这个能力我觉得很关键。
因为 coding agent 一旦工作时间变长，它就不一定只属于你当前那个终端窗口。
比如你让它跑一个迁移、修一个复杂 bug、重构一组文件。它可能要跑几分钟、十几分钟，甚至更久。
这个时候，如果你只能坐在终端前面盯着，就很浪费。
远程控制的意义是：agent 可以继续跑，你可以从网页上看进度，必要时补一句话，或者直接取消。
这更像一个后台 worker，而不是一个普通 CLI 程序。
自动上下文压缩：不用再手动 handoff
第二个变化，我觉得是这次最实用的：自动 compaction。
以前很多 AI 编程工具都会遇到一个问题：上下文快满了。
然后用户要开始焦虑：
要不要手动总结？
要不要开新 thread？
要不要 handoff？
哪些信息不能丢？
Amp 这次的判断很直接：2026 年的 frontier model 已经很擅长处理 compaction，所以工具就不应该再让用户手动管理上下文。
现在 Amp 会在上下文窗口达到 90% 时自动压缩当前 thread。
它会总结当前上下文，然后开启一个新的窗口继续跑。
也就是说，你不用盯着 context percentage，不用在 thread 里慌忙抽取信息，也不用手动 handoff。
原文里有一句挺有意思：他们在一次迁移过程中关掉了一天自动 compaction，结果大家都抱怨。一个 beta 用户的反馈大意是：我喜欢自动压缩，一点也不怀念 handoff。
所以这次 Amp 的态度很明确：handoff 退出，compaction 接上。
这个点我很认同。
如果 agent 真要变成长期工作的工具，上下文管理就应该是系统能力，不应该是用户每天要操心的事情。
插件 API：把工具、命令、UI 都开放出来
第三个大变化，是 Amp 正式发布 Plugin API。
Amp 插件现在可以做几类事情：
- 监听事件，比如 tool call、tool result、agent 生命周期
- 注册工具，让 agent 可以调用自定义 tool
- 注册命令，放到 command palette 里
- 弹 UI，比如通知、确认框、输入框、选择框
- 调 AI 做简单判断，比如 yes/no 分类，并返回置信度和理由
原文里举了一个 ask_user_choice 的例子。
它是一个插件工具，可以让 agent 在有多个方案时弹出选择题，让用户选一个。
这个方向很有意思。
以前很多 agent 工具的能力是写死的。你能用什么 tool，怎么确认权限，怎么和用户交互，都由产品本身决定。
插件 API 出来后，团队可以根据自己的工作流扩展 Amp。
比如你可以做一个权限插件，定义哪些命令需要审批；也可以做一个 CI 插件，把测试结果回传给 agent；还可以做一个内部知识库插件，让 agent 查团队文档。
这会让 Amp 更像一个 agent runtime，而不只是一个聊天式代码助手。
消息排队和 Steering：不要老是打断 Agent
这次 Neo 还改了消息交互方式。
现在，当 agent 正在工作时，你再发消息，默认不会马上打断它，而是进入队列。
这个设计看起来小，但其实很符合 agent 工作流。
以前我们经常会遇到这种情况：
agent 正在跑测试或者改代码，你突然想到一个补充要求。
你发出去吧，可能打断它当前工作。
你不发吧，又怕自己忘了。
消息队列解决的是这个问题：你可以先把想法丢进去，让它排着。
如果某条消息比较急，可以用 steering。
steering 的意思是：这条排队消息不一定要等 agent 完全空闲，而是在下一次合适时机尽快送进去。比如下一个 tool result 回来时。
当然，如果你真要马上打断，也可以按 Esc Esc。
这个设计让我感觉 Amp 在刻意减少“人类频繁拽 agent”的动作。
因为今天的模型能做更长的任务，我们的交互方式也要跟着变。不是每句话都要立刻插进去，而是让 agent 保持节奏，人在必要时 steering。
权限系统：默认不再逐个询问
这里有一个比较大胆的变化。
Amp 现在默认不再在运行工具前询问权限。
以前那个 --dangerously-allow-all，现在对没有配置权限的用户来说，变成默认行为。
当然，旧权限系统没有消失。它现在变成了一个内置插件。
如果你原来的设置里已经启用了权限，比如 amp.permissions、amp.dangerouslyAllowAll: false，或者 amp.guardedFiles.allowlist，Amp 还是会加载这个权限插件，行为保持不变。
为什么要这么改？
Amp 的解释很现实：一年前，工具调用比较简单。你看看 tool name、看看参数，做一些字符串匹配，好像就能判断允不允许。
但现在的 frontier model 会写临时脚本，会串联 shell 命令，会自己生成工具流程。
如果模型一下子写了几个 20 行 Python 脚本并行处理任务，你再靠检查里面有没有 rm -rf 来判断安全性，其实只是给自己一种安全错觉。
所以 Amp 把权限放到 Plugin API 里。
每个组织可以按自己的规则写权限策略。谁能调用什么工具，什么命令需要审批，哪些文件要保护，都可以自己做。
这个变化我觉得会有争议。
从产品效率上看，它是对的。频繁弹权限会打断 agent，也会让用户麻木。
但从安全上看，默认放开一定需要用户有清醒认知。尤其是团队环境、生产代码、敏感目录，不能直接裸跑。
所以我的建议是：个人实验可以默认快一点；公司项目一定要认真配权限插件。
性能：大 thread 终于不拖死 CLI
Amp 原文给了一个很直观的性能对比。
测试条件是一个大约 5000 条消息的 thread。
旧 CLI 平均 CPU 占用是 84.1%，新 CLI 是 17.4%，少了 79%。
旧 CLI idle 内存是 1814 MB，新 CLI 是 540 MB，少了 70%。
| 指标 | 旧 CLI | 新 CLI | 改进 |
|---|---|---|---|
| CPU 平均占用 | 84.1% | 17.4% | 少 79% |
| CPU 峰值 | 86.3% | 25.8% | 明显下降 |
| 空闲内存 | 1814 MB | 540 MB | 少 70% |
渲染性能也改善了。
Before：
After：
这个指标看起来不像功能发布那么性感，但对重度用户很关键。
因为 coding agent 的 thread 会越来越长。
如果一个工具在几千条消息后开始卡，用户就不敢让它长时间工作。你会本能地清空、重开、拆任务。
Neo 的目标很明显：让长线程成为默认，而不是异常。
删掉旧功能：Amp 不想让你按 2025 年的方式用 Agent
这次 Amp 还删了一些功能。
它们删掉 handoff，因为自动 compaction 已经接管了这个场景。
它们不再在你编辑或恢复消息时自动回滚文件改动。原因是模型现在已经足够会“自己撤销”，而旧 rollback 本来就是 best-effort。如果 agent 跑代码生成了文件，没有复杂 snapshot 很难完整追踪。
它们还取消了 skill management 的命令和子命令。Amp 仍然支持 Agent Skills，但添加、删除、更新更适合交给外部工具来做。
自定义主题也被删了。理由是主题太多会影响 CLI 的可读性、精致感和 Amp 自己的识别度。
另外，旧 CLI 里通过 $、$$ 手动调用 bash 的方式也没了。因为现在模型自己更会跑命令，而且上下文也不再那么容易爆掉。
这些删除动作背后的态度很清楚：
Amp 不想继续照顾旧时代 agent 的使用习惯。
当模型更能干，工具也应该少一点手动机制，多一点系统级自动化。
我的看法：AI 编程工具的竞争开始从“模型聊天框”转向“Agent 操作系统”
我觉得 Amp Neo 这次最有意思的，不是某一个功能。
远程控制、自动 compaction、插件 API、消息队列、权限插件、性能优化，这些功能拆开看都不难理解。
但放在一起看，它们指向的是同一件事：
AI 编程工具正在变成一个 agent runtime。
以前的 coding assistant 更像一个聪明聊天框。你问，它答；你让它改，它改；你盯着它，它跑。
现在方向开始变了。
Agent 会跑得更久，会跨设备被控制，会自己管理上下文，会通过插件接入组织策略和内部工具，会把用户消息排队，会在合适时机接收 steering。
这就不只是“AI 帮我写代码”了。
它更像一个长期工作的开发进程。
这也是为什么 CLI 还重要。
不是因为终端本身有什么情怀，而是因为终端离代码、文件、命令、测试最近。真正的 agent 需要贴近这些东西。
但 CLI 又不能只是本地小窗口，它还要能被远程控制、能长期运行、能被插件扩展。
Neo 做的就是这个方向。
当然，这条路也有风险。
默认放开权限这件事，一定会让一些人不舒服。自动 compaction 也可能在极端情况下丢掉某些细节。插件生态如果发展起来，也会带来新的安全边界问题。
但总体上，我觉得 Amp 的判断是对的：
2026 年的 AI 编程工具，不能再围绕“模型很弱，所以用户要随时看着它”来设计。
它应该围绕“模型已经能做更长任务，所以系统要让它可靠地长时间工作”来设计。
小结
Amp Neo 不是一次简单的 CLI 改版。
它更像是 Amp 对下一代 coding agent 工作流的一次重新下注：
让 agent 能远程控制，自动管理上下文，用插件扩展能力，用队列减少打断，用性能优化支撑长线程，用新的权限体系适配复杂工具调用。
对开发者来说，这类工具的变化会很快影响日常工作方式。
我们会越来越少盯着 agent 每一步怎么做，越来越多地把任务交给它跑，然后在关键节点接管、纠偏、验收。
这也是这篇 blog 值得搬运的原因。
它不是在讲一个 CLI 小版本，而是在讲 AI 编程工具接下来会怎么变。
信息来源
- Amp 官方原文：Amp, Rebuilt
- Amp Plugin API：ampcode.com/manual/plugin-api