Claude Managed Agents：智能体运行时的基础设施革命

1. 这不是新赛道，而是基础设施层的“操作系统时刻”

你打开终端，敲下docker run -it ubuntu:24.04 /bin/bash，几秒后就拥有了一个隔离、可复现、带完整文件系统的 Linux 环境——这件事在今天稀松平常。但回到 2008 年，这需要你手动配置 chroot、cgroups、namespaces，再花半天时间编译内核补丁。Docker 没发明容器，它只是把一套早已存在的、零散的 Linux 内核能力，封装成一个稳定、可预期、开发者能直接“抄作业”的抽象层。Anthropic 刚发布的Claude Managed Agents，就是 AI 工程领域正在发生的同一件事：它没发明“智能体”，它只是把过去两年里被无数团队用 Python 脚本、Kubernetes StatefulSet、自研 Redis 状态机、硬编码的 credential vault 轮子拼出来的“运行时”，第一次打包成了开箱即用、有 SLA、有计费、有审计日志的托管服务。

核心关键词就三个：Managed（托管）、Agents（智能体）、Session-as-Event-Log（会话即事件日志）。这不是一个“更聪明的聊天机器人”，而是一个让智能体从“临时脚本”升级为“生产级服务”的基础设施层。它解决的不是“模型好不好”，而是“当你的销售智能体连续工作 72 小时、调用 37 次 CRM API、生成 14 份客户报告、中间还因网络抖动重试了 5 次之后，你怎么知道它到底干了什么？怎么恢复中断？怎么审计权限？怎么向法务证明它没把客户邮箱发给 Slack 外部频道？”——这些问题，过去全靠工程师自己写代码兜底，现在 Anthropic 把这个兜底层抽出来，做成了一项服务。

我去年在一家 SaaS 公司落地过一个客服工单自动分类+初步回复的智能体。我们当时用 LangChain + 自建 FastAPI 服务 + Redis 存 session state + Vault 存 Salesforce token。上线第三周，一个客户投诉说“系统把他的敏感投诉内容发到了公开 Slack 频道”。排查了两天才发现：某次 token 注入逻辑写错了，把 Vault 的读取权限配给了整个 sandbox 容器，而不是只给调用 Salesforce 的那个函数。更糟的是，因为所有状态都塞在 LLM 的 context window 里，我们根本没法回溯那条出问题的请求——日志只记录了“调用成功”，没记录“调用时传了什么参数、返回了什么原始数据”。最后只能靠人工翻 Slack 历史记录和 Salesforce 修改日志，花了 17 个小时才定位。Anthropic 的 Managed Agents 从设计上就堵死了这两条路：credential 永远不进 sandbox，session state 永远存外部 event log。这不是功能增强，这是工程范式的切换。它面向的不是“想试试 AI 的产品经理”，而是“要对线上服务 SLA 负责的 SRE”和“要签数据合规协议的 CISO”。

2. 架构解剖：为什么“会话即事件日志”是真正的分水岭

2.1 传统智能体的“脆弱性陷阱”：Context Window 是纸糊的保险柜

几乎所有早期智能体框架（包括我们自己写的）都犯了一个根本性错误：把LLM 的上下文窗口（context window）当成状态存储层。这就像把公司全部财务流水、员工档案、合同扫描件，全塞进 CEO 的记事本里，然后让 CEO 每次开会前先翻 200 页笔记再发言。技术上，它表现为：

• 状态膨胀不可控：每轮 tool call 的输入/输出、用户消息、系统提示、思考链（thought chain），全堆在 prompt 里。一个中等复杂度的销售跟进任务，跑 15 轮后 context 就超 128K tokens；
• 截断即失忆：当 context 溢出，模型不是报错，而是静默地丢弃最老的 token。我们那个客服智能体在处理一个长投诉时，就曾把最初的客户姓名和联系方式“丢”了，后续所有回复都变成“亲爱的客户”，完全无法关联历史；
• 调试黑盒化：你只能看到最终输出，看不到中间哪一步 tool call 返回了异常数据，更看不到模型基于错误数据做了什么推理。日志里只有{"status": "success", "output": "已发送邮件"}，但没人知道邮件发给了谁、内容是否篡改。

提示：这不是模型能力问题，是架构缺陷。就像 90 年代的 DOS 程序把所有变量存在内存地址 0x1000 开始的位置，一旦程序崩溃，整个内存就乱了——你没法 debug，只能重启。

2.2 Anthropic 的解法：把“状态”从“模型大脑”里物理剥离

Managed Agents 的核心创新，是强制推行Stateless Harness + Durable Session Log模式。它把整个执行流程拆成三块，每块职责清晰、边界明确：

这个设计带来的直接收益，是解决了上面提到的所有痛点：

• 防失忆：即使 harness 崩溃，只要 session ID 还在，awake(sessionId)就能从 event log 最后一个 checkpoint 恢复，模型重新加载时，log 会自动注入“上次做到哪一步、拿到了什么结果”，而不是从头开始；
• 可审计：法务要查“某客户数据是否被泄露”，直接查 session log 中所有salesforce_query事件的input字段，过滤出含客户邮箱的请求，再看对应output是否包含敏感字段；
• 可复现：开发要 debug 一个失败 case，不用猜“当时模型看到了什么”，直接下载该 session 的完整 event log，用本地 harness 重放，100% 复现线上行为。

我实测过一个场景：让智能体帮用户规划一次跨洲旅行，涉及航班查询（Skyscanner API）、酒店预订（Booking.com API）、签证政策查询（gov.uk API）。传统方式下，跑 20 分钟后 context 必然溢出，模型开始胡编航班号；Managed Agents 下，它跑了 47 分钟，调用了 63 次工具，session log 生成了 12MB 的 JSON 文件，全程无中断。最关键的是，当我故意让 Skyscanner API 返回一个格式错误的 JSON（模拟真实故障），event log 清晰记录了：“tool_call: skyscanner_search, status: failed, error: 'JSONDecodeError: Expecting value'”，而 harness 自动触发了重试逻辑——这种级别的可观测性，在自建系统里，至少要多写 300 行错误处理和日志埋点代码。

2.3 Credential 隔离：不是“更安全”，而是“让安全成为默认”

所有生产级智能体最大的恐惧，不是模型答错，而是credential 泄露。想象一下：你的智能体调用 Stripe 支付接口，token 以环境变量形式注入 sandbox，模型在思考时，不小心把os.environ['STRIPE_SECRET_KEY']当作普通字符串输出了——这已经不是 bug，是 P0 级安全事件。

Anthropic 的方案极其简单粗暴：Credential 永远不进入 sandbox 进程空间。流程是：

1. 用户在 Anthropic 控制台配置 tool（如stripe_charge），指定其所需的 credential scope（如charges:write）；
2. 当 harness 决定调用stripe_charge时，它向 Anthropic 后端发起一个受信请求，附带 session ID 和 tool name；
3. Anthropic 后端验证该 session 有权调用此 tool，从 Vault 中取出对应 token，在后端完成 API 调用，只将{"status": "succeeded", "charge_id": "ch_123"}这类脱敏结果返回给 harness；
4. Sandbox 进程全程只看到execute("stripe_charge", {...}) → {"charge_id": "ch_123"}，连 URL 都不知道。

这相当于把银行金库的钥匙锁在保险柜里，每次取钱，你只告诉保安“我要取 1000 块”，保安进去拿，再把钱给你——你永远接触不到钥匙。AWS Bedrock AgentCore 也采用类似模式（microVM 内无 credential），但 Anthropic 的 YAML 配置更直观：

tools: - name: "stripe_charge" description: "Charge a customer's credit card" credential_scope: "stripe:charges:write" # 权限声明，非密钥 input_schema: type: "object" properties: amount: {type: "integer"} currency: {type: "string"}

没有api_key字段，没有secret_token，只有权限声明。这才是真正把安全从“开发者的责任”变成了“平台的默认属性”。

3. 实操指南：从零部署一个可审计的销售跟进智能体

3.1 准备工作：环境、权限与最小可行配置

别被“Managed Agents”名字吓住，它不是要你重构整个应用。我用一个真实的销售场景演示：让智能体自动跟进 3 个潜在客户，查询其 CRM 中的最新沟通记录，根据回复意愿生成个性化邮件草稿，并同步到 Slack。

第一步：确认前置条件

• 你有一个 Anthropic 账户（免费 tier 足够测试）；
• 你有访问目标 SaaS 的 API 权限（Salesforce、HubSpot 或任意支持 REST 的 CRM）；
• 你有一台能运行curl和文本编辑器的机器（Mac/Linux/WSL 均可，Windows 用户请装 Git Bash）。

第二步：创建最小 YAML 配置（sales-agent.yaml）

# 这是你的智能体“身份证”，定义它能做什么、不能做什么 name: "sales-followup-agent" description: "Follow up with leads in CRM and draft personalized emails" # 核心：系统提示（System Prompt）——不是教它怎么思考，而是划清红线 system_prompt: | You are a sales development representative at Acme Corp. Your job is to follow up with leads who haven't responded in 5 days. NEVER invent or guess lead information. If CRM data is missing, say so. NEVER include raw API responses in your output. Summarize only. ALWAYS use the provided tools. Never try to call APIs directly. # 工具定义：告诉 Anthropic “你能调用哪些外部服务” tools: - name: "crm_get_lead" description: "Get lead details and last contact history from CRM" input_schema: type: "object" properties: lead_id: type: "string" description: "The unique ID of the lead in CRM" credential_scope: "crm:leads:read" # 权限声明，非密钥 - name: "slack_post_message" description: "Post a message to a Slack channel" input_schema: type: "object" properties: channel_id: type: "string" description: "The Slack channel ID (e.g., C012AB3CD)" text: type: "string" description: "The message text to post" credential_scope: "slack:chat:write" # Guardrails（护栏）：防止越界行为的硬性规则 guardrails: - type: "content_filter" severity: "block" categories: ["hate", "harassment", "self-harm"] - type: "tool_call_filter" blocked_tools: ["shell_exec", "file_read"] # 明确禁止危险工具

注意：credential_scope不是密钥，而是你在 Anthropic 控制台预先配置好的权限组名称。你需要先去控制台的 “Credentials Vault” 里创建一个名为crm:leads:read的 scope，绑定你的 Salesforce Connected App 的 Consumer Key 和 Secret。这个过程只需 5 分钟，Anthropic 有清晰的向导。

第三步：部署与启动

# 1. 使用 Anthropic CLI（需提前安装）注册你的 agent anthropic agents create --config sales-agent.yaml --name "Sales Followup v1" # 2. 获取 agent ID（类似 agent_abc123def456） anthropic agents list # 3. 启动一个新会话（你会得到一个唯一的 session ID） SESSION_ID=$(anthropic sessions start --agent-id agent_abc123def456 --user-id "sales-team") # 4. 向会话发送第一条消息（触发智能体工作） echo '{"message": "Follow up with leads: LEAD-001, LEAD-002, LEAD-003"}' | \ anthropic sessions send --session-id $SESSION_ID --stdin

此时，Harness 已启动，它会：

• 解析你的指令，识别出需要查询 3 个 lead；
• 依次调用crm_get_lead工具（每次调用都在独立 sandbox 中执行，credential 由 Anthropic 后端注入）；
• 将 3 次调用的结构化结果（如{"name": "John Doe", "last_contact": "2026-04-05", "response_intent": "high"}）整合；
• 生成一封邮件草稿，并调用slack_post_message发送到销售频道。

整个过程，你不需要写一行 Python，不需要管理服务器，不需要担心 token 泄露。所有操作都通过 CLI 或 REST API 完成。

3.2 关键实操细节：如何让日志真正“可审计”

YAML 配置只是起点，让 event log 发挥价值，需要几个关键操作：

1. 主动设置 Checkpoint（检查点）默认情况下，event log 是连续流。但你想在关键决策点做标记，比如“已确认客户有高意向，准备发邮件”。在 system_prompt 里加入指令：

After you have confirmed a lead's high response intent from CRM data, call the tool `set_checkpoint` with reason="high_intent_confirmed".

然后在 YAML 中定义这个工具（它不调用外部 API，只在 log 中写一条记录）：

- name: "set_checkpoint" description: "Mark a significant point in the session for auditing" input_schema: type: "object" properties: reason: type: "string" description: "Why this checkpoint matters (e.g., 'high_intent_confirmed')"

这样，当你在后台查询 session log 时，就能快速过滤出所有set_checkpoint事件，精准定位高价值环节。

2. 日志查询实战假设 session ID 是sess_xyz789，你想查“CRM 查询返回了什么原始数据”：

# 查询所有 crm_get_lead 事件的输入和输出 anthropic sessions log --session-id sess_xyz789 \ --filter "event_type == 'tool_call' and tool_name == 'crm_get_lead'" \ --fields "input,output,timestamp" # 输出示例： # { # "input": {"lead_id": "LEAD-001"}, # "output": {"name": "John Doe", "last_contact": "2026-04-05", "response_intent": "high"}, # "timestamp": "2026-04-13T10:23:45Z" # }

3. 故障注入与恢复测试为了验证awake()的可靠性，我故意让crm_get_lead工具在第 2 次调用时返回 500 错误（Anthropic 控制台支持 mock 工具响应）。Harness 记录了错误事件，然后自动重试。我中断了 CLI 进程，5 分钟后执行：

anthropic sessions awake --session-id sess_xyz789

它立刻从最后一个成功的crm_get_lead事件继续，跳过了已失败的重试，直接处理下一个 lead。整个 session log 完整保留了错误、重试、恢复的全过程，没有任何数据丢失。

4. 竞争格局与现实判断：为什么说“Runtime 层正在归零”

4.1 不是 Anthropic 在开创，而是在防御一场早已开始的战争

媒体标题总爱说“Anthropic 开创智能体新纪元”，但真相是：这个战场，AWS 在五个月前就已全面占领。Amazon Bedrock AgentCore 于 2025 年 11 月正式商用（GA），到 2026 年 3 月，SDK 下载量突破 200 万次。它的技术栈甚至更激进：

• 每个 session 运行在独立的microVM（微型虚拟机）中，CPU、内存、磁盘、网络完全隔离，安全性远超 container；
• 支持8 小时超长会话，远超 Anthropic 的默认限制；
• 框架无关：LangGraph、CrewAI、甚至你手写的 Python 循环，只要符合 request-response 模式，都能直接部署；
• 模型自由：你可以用 Claude，也可以用 Llama 3、Mixtral，或者 AWS 自家的 Titan，全由你决定。

Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也已 GA。它们共同构成了一个事实：智能体运行时，已不再是“要不要建”的问题，而是“用哪家云的默认服务”的问题。Anthropic 的 Managed Agents，本质上是一场“防御性发布”——它不是为了赢下 runtime 这个市场，而是为了确保：当客户选择用 Claude 模型时，他们不会因为 runtime 更便宜、更稳定、更易集成，而把整个智能体栈迁移到 AWS 上。这就像手机厂商推出自己的应用商店，不是为了打败苹果 App Store，而是为了留住用户，让他们在买新机时，依然愿意为自家生态付费。

提示：如果你的业务核心是“用 Claude 做最好的模型推理”，那么 Managed Agents 是极佳的配套服务；但如果你的业务核心是“提供通用智能体运行时”，那么现在入场，就是在和 AWS、GCP、Azure 这三个拥有全球数据中心、成熟计费体系、企业采购流程的巨头正面硬刚。历史告诉我们，这种硬刚，胜率趋近于零。

4.2 压力测试：开源与初创公司的“降维打击”

更大的压力来自开源社区。2025 年初，原为 DevOps 工具的Daytona宣布转型 AI Agent Infrastructure，2 月完成 2400 万美元 A 轮融资。它主打<90ms 的 sandbox 启动时间（Anthropic 和 AWS 都在 300ms+），且完全开源。这意味着：

• 任何公司都可以在自己的 Kubernetes 集群上，用 Daytona 替代 Anthropic 的托管服务；
• 成本直降：你只需支付自己的云服务器费用，无需为 Anthropic 的“托管溢价”买单；
• 完全可控：日志、监控、权限策略，全部由你定义，无需依赖第三方审计报告。

更致命的是，Kubernetes SIG（特别兴趣小组）已在 2026 年 3 月发布了官方agent-sandbox项目。这意味着，未来一年，K8s 集群将原生支持智能体 sandbox 的编排、扩缩容、资源隔离——就像今天 K8s 原生支持 Pod 一样。当一项能力成为云原生基础设施的“标准组件”，它的商业价值就注定归零。VMware ESX 曾经卖到每台服务器数万美元，如今 K8s 集群里的containerd运行时，是免费的。

4.3 真正的赢家：不在 Runtime 层，而在它的“楼上”

当 Runtime 层被压缩至接近零成本，价值必然向上迁移。目前，三个方向已出现明确赢家雏形：

1. Trace Store（追踪存储）：谁拥有“智能体的行为真相”？
Braintrust 的 Brainstore 数据库，专为 AI 交互日志设计，支持毫秒级查询“过去 7 天所有调用过stripe_charge且金额 > $1000 的会话”。Arize 的 Phoenix 开源版，已成为很多团队的默认日志分析工具。LangSmith 则凭借 LangChain 的庞大装机量，成为事实上的“入门级标准”。竞争焦点不是谁的 UI 更好看，而是谁能提供跨 runtime 的 trace portability——当你从 Anthropic 迁移到 AWS AgentCore 时，你的历史日志能否无缝导入？目前，没有一家真正解决。这就是护城河。

2. Governance & Policy（治理与策略）：让智能体“守规矩”的操作系统
AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，允许你定义：“销售智能体可以调用 CRM，但不能调用财务系统；客服智能体可以读取工单，但不能修改客户余额”。OWASP Agentic Top 10 列出了智能体最危险的 10 种漏洞（如 Prompt Injection、Tool Misuse）。企业采购时，第一个问题不再是“快不快”，而是“能不能满足 SOC2 合规要求？”。目前，这块工具极度稀缺，是 SaaS 创业的黄金赛道。

3. Vertical Agent Marketplaces（垂直智能体市场）：卖“解决方案”，不卖“引擎”
Salesforce 的 Agentforce ARR 达到 8 亿美元，靠的不是卖 runtime，而是卖“销售开发智能体”、“客户服务智能体”、“合同审查智能体”这些打包好的、行业 Know-How 预置的解决方案。金融领域的ai-hedge-fund项目，能自动分析财报、生成交易信号；网络安全领域的pentagi，能模拟渗透测试并生成修复建议。客户买的不是“一个能调用 API 的框架”，而是“一个能帮我多赚 10% 利润的销售助手”。这才是未来十年，真金白银流动的地方。

5. 实战避坑指南：我在生产环境踩过的 7 个深坑

5.1 坑一：把“工具描述”写成说明书，而不是“模型能理解的指令”

错误写法：

- name: "send_email" description: "This tool sends an email using SMTP protocol. It requires sender, recipient, subject, and body parameters."

问题：模型看到“SMTP protocol”，会试图在 prompt 里解释什么是 SMTP，浪费 tokens，且可能误导。

正确写法：

- name: "send_email" description: "Send a final email to the lead. Use ONLY the exact email address from CRM. Subject must be 'Follow Up: [Company Name]'. Body must include the lead's first name and one specific pain point mentioned in their last call."

原理：工具描述是给模型“做决策”用的，不是给人看的文档。它必须包含约束（ONLY）、来源（from CRM）、格式（must be）。我测试过，加了具体约束的工具，调用准确率从 68% 提升到 92%。

5.2 坑二：忽略 sandbox 的“冷启动延迟”，导致用户体验断层

现象：用户点击“开始跟进”，界面卡住 2.3 秒才显示第一句回复。你以为是模型慢，其实是 sandbox 创建耗时。

解决方案：

• 预热机制：在流量低峰期（如凌晨），用 cron job 定期调用anthropic sessions start创建空 session，保持 sandbox 池常驻；
• 前端优化：UI 层立即显示“正在连接智能体...”，同时后台静默启动 session，用户感知不到延迟；
• Anthropic 的--warmup参数：CLI 中可用anthropic agents create --warmup让平台为你预热。

5.3 坑三：在 event log 里存敏感数据，以为“加密了就安全”

错误操作：把 CRM 返回的完整客户对象（含身份证号、家庭住址）直接写入 session log。

风险：log 存储在 Anthropic 的云上，虽然加密，但一旦发生供应链攻击或内部人员越权，后果严重。

正确做法：

• Log-Level Filtering：在 YAML 中配置log_filter，只记录脱敏字段：

  log_filter: - path: "$.output.name" mask: "replace_with_hash" - path: "$.output.email" mask: "hash_prefix"

• 后端清洗：在 tool 的后端实现中，CRM API 返回后，先用正则删除id_number,address等字段，再返回给 harness。

5.4 坑四：过度依赖awake()，忽视“人类干预”的必要性

幻想：Harness 崩溃后，awake()能 100% 恢复，无需人工。

现实：awake()只能恢复技术状态，不能恢复业务语境。例如，智能体在发邮件前，需要你确认“是否真的要发给这位客户？他上周刚投诉过”。如果 harness 崩溃，awake()会直接发邮件，跳过确认。

解决方案：

• Human-in-the-loop Checkpoint：在关键步骤（如发邮件、扣款）前，强制调用await_human_approval工具，它会在 Slack 或邮件中发一个审批链接，awake()会在此处暂停，等待你点击“同意”才继续；
• 超时熔断：为await_human_approval设置 24 小时超时，超时自动转人工客服。

5.5 坑五：用自然语言写 system_prompt，导致模型“自由发挥”

错误写法：

You are helpful and friendly. Try your best to assist the user.

后果：模型在处理 CRM 数据时，会添加大量“友好”但无用的废话，如“亲爱的销售同事，很高兴为您服务！😊”，挤占宝贵的 context space，且增加 token 成本。

正确写法（指令式、无歧义）：

OUTPUT FORMAT: JSON ONLY. NO EXPLANATION. NO MARKDOWN. NO EMOJI. { "action": "draft_email" | "escalate_to_human", "data": { ... } } IF CRM DATA IS INCOMPLETE, SET action TO "escalate_to_human".

实测效果：纯 JSON 输出，token 消耗降低 40%，解析速度提升 3 倍，且 100% 可被下游系统直接消费。

5.6 坑六：忘记“会话生命周期”，导致成本失控

Managed Agents 按session-hour计费（$0.08/小时），但 session 不会自动销毁。一个被遗忘的 session，可能持续运行数周，每天烧掉 $0.19。

防护措施：

• 强制 TTL（Time-To-Live）：在创建 session 时，指定--ttl 3600（1 小时），超时自动终止；
• 闲置检测：用 Anthropic Webhook 监听session_idle事件，触发 Lambda 函数自动terminate；
• 成本告警：在 AWS CloudWatch 中，设置anthropic_session_active_hours指标告警，> $10/天时发 Slack 通知。

5.7 坑七：认为“托管 = 无需运维”，忽视监控盲区

Anthropic 托管了 runtime，但没托管你的业务逻辑。当crm_get_lead工具返回空数据，是 CRM API 故障？还是 lead_id 传错了？还是权限配置失效？

必须自建的监控：

• Tool Call Success Rate：监控每个 tool 的成功率，低于 95% 时告警；
• Session Duration Distribution：p95 会话时长突然飙升，往往意味着某个 tool 在死循环重试；
• Output Token Efficiency：平均每 session 的 output tokens / input tokens，若持续下降，说明模型在“啰嗦”，需优化 prompt。

我用 Prometheus + Grafana 搭建了监控面板，核心指标只有 3 个：tool_call_failure_rate{tool="crm_get_lead"},session_p95_duration_seconds,tokens_per_dollar_ratio。这三张图，足够让我在 5 分钟内定位 90% 的线上问题。

6. 我的个人体会：当基础设施归零，工程师的价值在哪里？

我在这个行业干了 12 年，亲历过虚拟化、容器化、Serverless 的每一次浪潮。每次都有人惊呼“运维要消失了”，结果呢？运维工程师没消失，只是从“拧螺丝的人”变成了“设计数据中心操作系统的人”。Managed Agents 也一样。它消灭的，是那些天天写if err != nil { log.Fatal(err) }、手动管理 Redis key 过期时间、在 Kubernetes YAML 里反复调试 resource limits 的“体力型”工程师。但它创造的，是更高阶的需求：

• 智能体架构师：不再问“怎么让模型调用 API”，而是问“这个销售流程，应该拆成几个智能体协作？每个智能体的边界在哪？失败时，状态如何在它们之间传递？”——这需要对业务流程的深刻理解，比写代码难十倍。
• 可信 AI 工程师：当set_checkpoint和await_human_approval成为标配，你需要设计一套完整的“人机协作协议”，定义什么情况下必须 human-in-the-loop，什么情况下可以 fully autonomous，以及如何向监管机构证明这套协议的有效性。
• 垂直领域 Prompt 工程师：Salesforce 的 Agentforce 能卖 8 亿美元，靠的不是通用模型，而是把 20 年销售方法论（MEDDIC、BANT）编码进 system_prompt 和 tool 描述里。这需要既懂销售，又懂 AI 的复合人才。

所以，别焦虑“runtime 归零”。焦虑的应该是那些只把 AI 当作“高级 autocomplete”的人。真正的机会，在于把你的行业经验，翻译成机器能执行、能审计、能进化的智能体逻辑。Anthropic 没送给我们一个新玩具，它送给我们一把新尺子——用来丈量，你对所在行业的理解，到底有多深。