Claude Duet 进入研究预览：常驻的主动型 Agent，和它必须先回答的三个问题

2026 年 10 月 21 日，Anthropic 宣布了 Claude Duet：一个面向专业人士与小企业主的主动型 Agent，以「研究预览」形式上线，提供 iOS 与 Android 独立应用，也可以通过网页端的 Claude 使用。按 The Verge 的报道，它基于 Claude Opus 5.5，每天早上给你一份简报，汇总已连接应用里最重要的几件事；一天之中持续盯着这些应用，只在需要你注意时才发消息；你也可以把各种任务交给它——从安排会议这类琐事，到用几十个工具搭仪表盘、做财务或销售预测、做原型、甚至构建 Web 应用。它带着一个装有浏览器的虚拟机，可以自己动手干活；在付款、删除这类大动作之前，它会先发消息征求批准。Anthropic 也说得很坦白：这是早期版本，它可能误读一段对话，也可能误判什么才是紧急的。这句话才是重点——常驻 Agent 的难点从来不是能力，是判断力与权限。

主动型 Agent 的核心不是能力，而是权限边界

一、Duet 到底做了什么

把官方描述拆开，功能可以归成四块。第一块是「主动摘要」：每天早上跨已连接应用汇总要点，这是主动型 Agent 与聊天机器人的分界线——它不等你问。第二块是「持续监看」：整天盯着这些应用，只在需要你介入时推送，这意味着它必须自己判断「什么算需要」——也正是误判最容易发生的地方。第三块是「代你做任务」：它不仅读，还写、还算、还调用工具，官方举例包括搭仪表盘、做财务与销售预测、做原型、建 Web 应用。第四块是「审批与安全」：它复用了连接在 Claude 上的记忆、技能与应用，带一个装了浏览器的虚拟机，并在付款或删除这类动作前请求批准；此外它有一套专门的分类器与安全系统提示词，设计目标是拒绝分享最严格层级的信息，比如信用卡号。可访问性上，它是研究预览，需要排队，且当前面向美国地区的 Pro 或 Max 订阅者。

# 1) Classify actions by consequence, not by prompt wording.
#    The model decides WHAT it wants; this table decides whether it may.
POLICY = {
    # read-only: safe to run unattended, still logged
    "list_messages":   {"class": "read",        "approval": False},
    "search_files":    {"class": "read",        "approval": False},
    # reversible writes: run, but require an undo record
    "create_draft":    {"class": "write",       "approval": False, "undo": "delete_draft"},
    "schedule_event":  {"class": "write",       "approval": True},
    # irreversible or money-moving: always human
    "send_payment":    {"class": "destructive", "approval": True, "hard_block": True},
    "delete_record":   {"class": "destructive", "approval": True, "hard_block": True},
    "share_contact":   {"class": "destructive", "approval": True, "hard_block": True},
}

def may_execute(action: str, approved: bool) -> tuple:
    rule = POLICY.get(action)
    if rule is None:
        return False, "unknown action"          # default deny, always
    if rule.get("hard_block") and not approved:
        return False, "requires explicit approval"
    if rule["approval"] and not approved:
        return False, "requires approval"
    return True, "ok"

二、常驻 Agent 的三种失败模式

第一种是误读：它把一段对话理解错了，然后基于错误的理解去建议、甚至去行动。Anthropic 自己写明了这个风险。第二种是误判紧急度：它每天给你一份简报，如果简报里塞了二十条「紧急」，它第二天就被你折叠进垃圾箱了——这不会马上造成事故，但会缓慢摧毁它存在的意义，因为一个被忽略的主动 Agent 和一个不存在的 Agent 没有区别。第三种最危险，是越权动作：它的权限来自你连接的应用，而连接一次等于授予长期访问权；一个常驻 Agent 会在你忘记的时候继续持有这些权限。前两种失败是可观察、可修正的；第三种失败往往是不可逆的，因为它涉及钱、数据外发与删除。所以对这类产品的评估顺序应该反过来：先看它怎么限制第三种，再看它怎么缓解前两种。

# 2) An approval request must state the blast radius, or people rubber-stamp it.
def approval_request(action: str, params: dict, preview: dict) -> dict:
    return {
        "action": action,
        "summary": preview["summary"],            # one line, human language
        "target": preview["target"],              # which record, which account
        "reversible": preview.get("reversible", False),
        "undo_window_minutes": preview.get("undo_window", 0),
        "evidence": preview["evidence"],          # the exact source it acted on
        "deadline": preview.get("deadline"),      # when it expires unanswered
    }

# Three rules that keep approval meaningful:
#   1. Never batch unrelated approvals into one tap.
#   2. Expire the request instead of re-asking louder.
#   3. If evidence is missing, refuse rather than ask a vague question.
# An approval dialog with no evidence trains people to tap yes.

三、审批闸：按动作后果分级，不按提示词分级

很多团队做审批闸的做法是让模型自己判断「这个操作危不危险」，然后决定要不要问人。这个设计有个根本问题：判断危险等级这件事，恰恰是模型最容易出错的部分，你不能用它来兜它自己的错。正确的做法是把分级写在代码里，按动作的后果分三类。只读类，可以无人执行，但要留日志。可逆写类，可以执行，但必须同时生成撤销记录，并给出撤销窗口。不可逆或涉及钱与数据外发的类，永远要人批准，且默认拒绝——动作不在白名单里就拒绝，而不是「不认识就放行」。第一段代码就是这张表的骨架：每个动作对应一个类别、是否需要审批、是否有硬阻断。它很短，但它是整个系统里唯一不依赖模型判断的地方。

# 3) Log every decision with its inputs. This is the only defense after
#    the fact, and the only way to debug an agent that "felt wrong".
import json, time, uuid

def audit(event: dict) -> None:
    row = {
        "id": str(uuid.uuid4()),
        "ts": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
        "agent": event["agent"],
        "action": event["action"],
        "class": POLICY.get(event["action"], {}).get("class", "unknown"),
        "inputs_hash": event["inputs_hash"],      # hash, not the payload
        "target": event.get("target"),
        "approved_by": event.get("approved_by"),  # human id, or None
        "approved_at": event.get("approved_at"),
        "result": event.get("result"),
        "undo_available": event.get("undo_available", False),
    }
    with open("agent_audit.jsonl", "a") as f:
        f.write(json.dumps(row, ensure_ascii=False) + chr(10))

# Store a hash of the inputs, not the inputs. You need to prove what it
# acted on, not to keep a second copy of everything it read.

四、代码：分级、审批、审计、权限、排序

第一段是动作策略表与执行判定：未知动作默认拒绝，硬阻断类必须显式批准。第二段是审批请求的结构：一行人类语言的摘要、目标对象、是否可逆、撤销窗口、证据来源、过期时间。这里有三个容易被忽略的规则：不要把多个不相关的审批塞进一次点击；没人回应时让请求过期，而不是反复催；如果证据缺失，就直接拒绝，而不是问一个含糊的问题——一个没有证据的审批弹窗，训练出来的只是盲点「同意」。第三段是审计日志：记哈希而不是原文，你需要证明它拿什么做了什么，不需要再存一份它读过的全部内容。第四段是权限盘点：连接前比对「实际申请的 scope」与「你定义需要的」，多出来的一律拒绝。

# 4) Inventory the scopes behind every connected app before you connect them.
SCOPES = {
    "mail":   ["read:inbox", "send:draft"],
    "calendar": ["read:events", "write:events"],
    "banking": ["read:balance"],          # read only. no payments. none.
    "crm":    ["read:contacts", "write:notes"],
}

def too_broad(granted: list, needed: list) -> list:
    return [s for s in granted if s not in needed]

for app, granted in connect_requests.items():
    extra = too_broad(granted, SCOPES.get(app, []))
    if extra:
        print("refuse:", app, "requests scopes you never defined:", extra)

# Rule: if an app offers "full access" and you only need reads, request
# reads. An always-on agent accumulates permissions silently; the only
# audit that works is the one that runs before the grant.

五、在连接应用之前先算一笔账

常驻 Agent 的权限是累积的，而且往往在一次「快速授权」里就定型了。所以第五段之前的动作，是在点授权按钮之前先写一张表：每个应用，你真正需要哪些 scope。表里的规则很简单：如果应用提供「完整访问」，而你只需要读，就只要读；涉及银行、支付类的应用，只给读余额，不给转账；涉及通讯录的应用，不给导出权限，因为通讯录外发是不可逆的。第四段代码做的是「超范围检测」：把实际授予的 scope 与你定义需要的比对，多出来的打印出来并拒绝连接。这套做法在个人使用场景里看起来有点过度，但请想清楚一件事：你把一个会主动行动的 Agent 接进了邮箱、日历和财务系统，它每一次误判都发生在这些系统里，而它的权限是你一次性给的。授权前的十分钟，比事后的十小时便宜。

# 5) A daily brief is a ranking problem. Make the thresholds explicit.
URGENT = {"deadline_hours": 24, "mentions_me": True, "money_above": 0}
MAX_ITEMS = 5

def score(item: dict) -> int:
    s = 0
    if item.get("deadline_hours", 999) <= URGENT["deadline_hours"]:
        s += 3
    if item.get("mentions_me") and URGENT["mentions_me"]:
        s += 2
    if item.get("money", 0) > URGENT["money_above"]:
        s += 3
    if item.get("from") == "boss":
        s += 2
    return s

brief = sorted(items, key=score, reverse=True)[:MAX_ITEMS]

# Anything the model wants to include but scores 0 goes to "nothing urgent".
# An agent that reports everything urgent teaches you to ignore it, and
# that habit is the actual failure: it does not cost accuracy, it costs trust.

六、研究预览阶段的现实建议

如果要用这类产品，我的建议是分三段走。第一段只给只读权限：邮箱、日历、文档，全部只读，先让它跑两周，看它每天给你的简报里有多少是真有用的、有多少是误判。这一步测的是它的判断力，而且没有任何风险。第二段开可逆写：让它创建草稿、排日程、写备注，但所有对外发送的动作仍然要你手动点。这一步测的是它的执行力与你的审查负担——如果审查它比自己做还累，那就不值得。第三段才考虑不可逆动作，而且只给最小范围：比如只允许在特定账户、特定金额以下、对特定收款方发起付款。永远不要给它一个「什么都行」的主账号。最后记住 Anthropic 自己的那句话：这是早期版本，它可能误读对话、误判紧急度——这不是营销免责声明，这是使用说明书。