AREX Feed Article
Anthropic 更新 Claude Managed Agents：ant CLI 新增会话查看器，工具调用引入 auto mode
Anthropic 面向开发者的官方账号 @ClaudeDevs 在北京时间 9 月 11 日凌晨（UTC 时间 9 月 10 日 18:43）连发两条推文，宣布 Claude Managed Agents 的两项更新：一是 ant CLI 新增会话查看器（session viewer），ant beta:sessions connect 可以把终端接上一个正在运行的会话，加 --web 参数则打开一个由 localhost（本机回环地址）提供服务的 Web 界面；二是新增 auto mode，Claude 会基于 user.message 事件里的用户意图审查每一次工具调用，并决定是执行、拒绝该调用，还是向用户请求输入。两项功能均为 Anthropic 官方发布口径，见和。
其中会话查看器一项已经可以超出推文口径核对：Anthropic 官方文档中的 完整写明了这条命令的行为边界，包括终端里能看到什么、能替用户做哪些决定。auto mode 的处境则不同——截至发稿，的策略表里仍然只列着 always_allow 和 always_ask 两种类型，auto 只出现在推文和 sessions-connect 页面的只言片语中。
ant beta:sessions connect：跟着会话跑，也能中途接手
按官方文档的描述，ant beta:sessions connect 会加载指定会话的完整 transcript（会话记录），然后实时跟随正在工作的 agent。终端视图显示对话、消息和工具调用，每个调用附带执行时长和结果；一条状态栏标明会话当前是运行中、空闲，还是在等待用户批准。在多 agent 会话里，终端视图跟随会话的主线程，包括协调者（coordinator）与它委派的 agent 之间的消息往来。
这个「查看器」并不只是看。文档列出的按键里，Enter 把输入作为 user.message 事件发出，Esc 发出 user.interrupt 中断正在运行的 agent，Ctrl+O 切换工具输入输出、token 用量和状态事件的详情显示。当某个工具调用等待批准时，输入行会变成「Allow tool call?」，用户选 Yes、No，或者「No，并告诉 agent 原因」——选择以 user.tool_confirmation 事件发出，输入的理由作为 deny_message 传回。中断不会终止会话：Ctrl+C 只是断开（detach），会话继续运行，重新连接时会加载完整历史；只有会话被终止或删除后，视图才变成只读。
没有交互终端的场景另有出路：脚本中使用 ant beta:sessions:events stream 和 ant beta:sessions:events send，这是文档明确给出的替代路径。
--web 打开浏览器界面，链接两分钟内有效，凭据不出本机
--web 参数走的是另一条通道：它把 Claude Console 的会话查看器从本地服务器（127.0.0.1）上提供服务，打印出 URL 并打开浏览器，加 --no-browser 可以跳过自动打开。浏览器里同样可以发消息、中断 agent、批准或拒绝工具调用，而且与终端视图不同，浏览器查看器跟随多 agent 会话的每一个线程，而不是只有主线程。
文档对安全性写得很具体：打印出的 URL 只能打开一次，在打印后两分钟内有效，刷新已打开的标签页可以，换地方打开则要重新执行命令；用户的凭据从不离开 CLI，页面只向本地 ant 进程发请求，由后者去调 API；本地服务器一直运行到用户按下 Ctrl+C。在推文评论区，开发者 是「不用再做端口转发了对吧」，指的正是这套本地服务加一次性 URL 的组合。
auto mode 的配置位置写在公告卡片里
推文附带的公告卡片给出了 auto mode 的配置方式：卡片标题为「Auto mode for Claude Managed Agents」，副标题为「由服务器评估工具调用」；代码示例里一个名为 Ops Agent 的 agent（模型 claude-fable-5-1）在 agent_toolset_20260401 的 default_config 中把 permission_policy 设为 { type: "auto" }。
要理解 auto 加在哪里，得看 Managed Agents 原有的权限框架。官方权限策略文档规定，权限策略只管服务器执行的工具（预置的 agent 工具集和 MCP 工具集）：always_allow 自动执行，always_ask 暂停会话等待批准；agent 工具集默认 always_allow，MCP 工具集默认 always_ask。走 always_ask 时，会话先发出 agent.tool_use 或 agent.mcp_tool_use 事件，然后以 session.status_idle 事件的 stop_reason.type 为 requires_action 停下来，等用户逐条发送 user.tool_confirmation。auto 是这套体系里的第三种取值，行为按推文口径是让模型裁决。sessions-connect 文档还写明了它的退回路径：当服务器「无法作出判断」（reaches no determination）时，仍回到终端里那个「Allow tool call?」提示，由人来定。
default_config 的粒度成了评论区追问的焦点
推文发出后，开发者的提问集中在 auto 的适用范围和判定依据上。，截图把 permission_policy 放进了工具集的 default_config，意味着 auto 一次性作用于 agent_toolset_20260401 里的所有工具，他追问这是否意味着存在按工具覆盖的配置。文档记录的按工具覆盖确实存在——configs 数组可以为单个工具（比如 bash）单独指定策略——但截至发稿，检索到的文档示例里只出现 always_allow 和 always_ask 两种取值，auto 能否按工具粒度设置，官方文档没有说明。
更直接：auto 的 allow/deny/ask 判断只看最新一条 user.message，还是用完整的会话历史和 agent 策略？能不能钉住规则（比如永远拒绝 rm、永远放行只读 bash 命令）？这些问题指向的正是 auto 与传统规则引擎的分界，在检索到的推文串里未见 Anthropic 的公开回应。
已有的使用者经验则提示了会话查看器的局限。，connect 有用，但他反复碰到的失败模式是「在模型已经在错误的分支上烧掉 60% 上下文之后才接上去——你看到了问题，损失已经造成」。
推文发出约 11 个小时后，第一条推文有约 122,559 次浏览、1,013 个赞和 62 次转发，@ClaudeDevs 的粉丝数为 685,591。悬而未决的仍是那几个具体问题：权限策略文档的策略表何时收录 auto，auto 的判定是否纳入完整会话历史、能否按工具粒度配置，Anthropic 截至发稿都没有公开说明。