{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "启示录",
  "home_page_url": "http://127.0.0.1:4321",
  "feed_url": "http://127.0.0.1:4321/feed.json",
  "description": "MJ 对科技、数据、商业和有趣事物的观察笔记",
  "language": "zh-CN",
  "items": [
    {
      "id": "http://127.0.0.1:4321/blog/2026-04-30-claude-managed-agents/",
      "url": "http://127.0.0.1:4321/blog/2026-04-30-claude-managed-agents/",
      "title": "Managed Agents 解决的和没解决的",
      "content_text": "当 Anthropic 在 4 月 8 日发布 Managed Agents 的时候，科技圈的兴奋是肉眼可见的。一条推文写道\"整个 YC 的一批创业公司要哭了\"，两小时内浏览量冲到 200 万。我花了两周时间深挖这件事——读官方文档、跟踪社区实测、分析企业案例——得出的结论是：这确实是 2026 年 AI 领域最重要的基础设施发布，但它解决的问题和没解决的问题同样值得关注。\n\n 今天这篇文章，我想认真聊聊：它到底做了什么、为什么重要、以及我们该抱着什么心态去看待它。\n\n 一句话说清楚它是什么\n\nClaude Managed Agents = Anthropic 托管的 AI Agent 运行平台。\n\n你定义 Agent（模型 + 指令 + 工具），Anthropic 负责让它稳定地跑起来——包括沙箱隔离、状态持久化、错误恢复、安全管控。你可以同时部署多个 Agent，各自独立运行，各有各的职能。\n\n用一个比喻：以前 AI Agent 像是你自己攒的台式机——性能可以很强，但系统装配、维护、稳定性全得自己搞。Managed Agents 像是给你提供了云主机服务——你只管用，底层的事平台全包了。\n\n\n\n 它实际解决了什么问题\n\n问题一：Agent 开发中 80% 的工作量不在 Agent 本身。\n\n根据Linas Newsletter 的分析，把一个 AI Agent 推到生产环境，通常需要 48 名高级工程师投入 36 个月——不是因为 Agent 逻辑难写，而是沙箱、状态管理、凭证隔离、容器运维这些基础设施太重了。Managed Agents 把这层全接走了。\n\n问题二：Agent 跑着跑着就崩了，进度全丢。\n\nManaged Agents 的架构把\"思考\"和\"执行\"解耦：容器崩了，系统自动换一个新容器从上次的检查点接着跑。这让 Agent 可以可靠地运行数小时甚至更长时间。\n\n问题三：想同时跑多个 Agent，运维成本指数级增长。\n\n现在你可以通过 API 定义多个不同职能的 Agent，独立启动、独立监控、互不干扰。一个人就能管理一组 Agent——不再需要一个工程团队来维护每个 Agent 的运行环境。\n\n 实际数据：跑起来是什么体验\n\n根据 NextFuture 的技术深度拆解和 The AI Corner 的开发指南，开发者社区已经涌现出大量实测数据：\n\n 深度调研 Agent：给它一个研究问题，它自动拆解子问题、并行搜索、深读原文、综合成带引用的报告。简单问题 50 秒搞定，花费约 ¥1；复杂研究 25 分钟，花费约 ¥10。\n\n 代码审查 Bot：一位开发者花 30 分钟从零做出可用于生产的 PR Review Agent。用自建方案通常需要 3 天。\n\n一个有趣的发现是：最大的成本项不是 AI 生成文字的费用，而是\"读资料写入记忆\"的费用——占总成本的 75%。Agent 越认真（读越多资料），花费增长越快。\n\n据 SiliconANGLE 的报道和 PYMNTS 的行业分析，五家企业已经将 Managed Agents 投入生产：\n\n Notion：用户在工作空间内直接给 AI 派活——写代码、做 PPT、生表格，同时启动数十个 Agent 并行工作。\n\n 乐天（Rakuten）：五个部门各配了一个专属 AI 助手，每个一周内上线（传统需要 36 个月），关键错误率降低 97%。\n\n Sentry：实现了\"发现 Bug → 分析根因 → 写修复 → 跑测试 → 提交 PR\"的全自动闭环。\n\n Asana：CTO 表示用 Managed Agents 交付高级 AI 功能的速度\"大幅加快\"（HelpNetSecurity 报道）。\n\n 冷思考：两个不该忽视的问题\n\n数据好看归好看，但有三件事值得清醒地想一想。\n\n第一，\"搭 Agent 容易\"不等于\"做好 Agent 容易\"。\n\n基础设施的门槛消失了，但 Agent 质量的门槛一点没降。一个 Agent 好不好用，90% 取决于你的指令写得够不够精准、任务拆解够不够合理。就像外卖平台让开餐厅不用租门面了，但菜好不好吃，还是厨师说了算。\n\n第二，长时间自主运行 = 长时间没有人类兜底。\n\nManaged Agents 的核心场景是让 AI 自己跑 25 分钟甚至数小时。但每多一步决策，出错概率都在累积——AI 在第 3 分钟做了一个微妙的错误判断，后面 22 分钟可能都建立在错误之上。社区反馈也提到，长时间运行（48 小时）的 Agent，运行成本可能反超 token 成本。\n\n\n\n 我的判断：谁该兴奋，谁该观望\n\n现在就该用的人：\n\n 独立开发者和小团队——终于不需要为 Agent 基础设施发愁了\n 做内部效率工具的——数据不敏感，容错空间大\n 想快速验证 AI Agent idea 的创业者——从 3 个月缩短到 3 天\n\n应该观望的人：\n\n 处理敏感数据的企业——等私有部署和合规认证\n 对输出质量有刚性要求的场景——等可靠性和评估体系成熟\n 已经有多模型策略的团队——单一模型绑定是硬伤\n\n 更大的图景：AI 正在从\"工具\"变成\"劳动力\"\n\n抛开具体产品不谈，Managed Agents 代表的趋势是不可逆的：AI 正在从\"你问它答\"的工具，变成\"你分配任务它自己完成\"的劳动力。\n\n这意味着我们和 AI 的关系在发生根本性转变——从\"使用者\"变成\"管理者\"。\n\n而\"管理 AI\"和\"管理人\"一样，需要的核心能力是：\n\n 能清晰地定义任务和预期\n 能设计合理的工作流程\n 能判断输出质量的好坏\n 能在对的环节设置检查点\n\nManaged Agents 降低了\"手\"的门槛，但\"脑\"的门槛从未降低。\n\n 如果你想试试，从这里开始\n\n1. 选一件你每天重复做的 3 步以上的事——比如整理信息、写周报、监控竞品\n2. 用官方模板起步——Deep Researcher 或 Field Monitor 模板最容易出效果\n3. 先跑一个，验证价值后再扩展——别一上来就规划 10 个 Agent 的矩阵\n4. 把精力花在写好指令上——这是决定 Agent 好坏的唯一杠杆\n\n技术在进步，门槛在降低。但无论工具多强，真正稀缺的永远是：想清楚该让 AI 做什么，以及怎么确保它做对了\n\n延伸阅读：Anthropic 官方文档 ｜ Linas Newsletter 完整指南 ｜ NextFuture 技术拆解",
      "summary": "",
      "date_published": "2026-04-30T00:00:00.000Z",
      "tags": [
        "技术观察",
        "AI"
      ]
    },
    {
      "id": "http://127.0.0.1:4321/blog/2026-04-25-ai-analysis/",
      "url": "http://127.0.0.1:4321/blog/2026-04-25-ai-analysis/",
      "title": "如何让 AI 真正做好数据分析？",
      "content_text": "最近我一直在琢磨一个问题：AI 都这么强了，为什么让它做数据分析，出来的东西总差点意思？\n 我和 AI 做了好几轮深度对谈，把这个问题翻来覆去地拆了一遍。结论有点反直觉——问题不在模型能力，而在一些更本质的东西。这篇文章就是把这些思考整理出来，希望对同样在折腾 AI + 数据分析的朋友有点启发。\n\n\n\n 四层难点：比想象的要深\n\n我把 AI 做数据分析的难点拆成了四层，越往下越扎心。\n\n 第一层：AI 不知道\"你到底想分析什么\"\n\n领导说一句\"看看留存怎么样\"，一个老练的分析师脑子里瞬间会闪过一串问题：谁要看？为什么现在看？是要做汇报还是要做决策？关心整体还是某个渠道？要挖多深？\n\n这些问题的答案，决定了分析怎么做。但这些答案全都是隐性的——它藏在你对业务节奏的理解里，藏在你和领导上周的一次聊天里，藏在你对团队 KPI 的判断里。\n\nAI 统统不知道。\n\n所以它要么给你一个面面俱到但毫无重点的\"全家桶分析\"，要么给你一个看起来专业但完全没回答到点子上的报告。两种都让人头疼。\n\n更要命的是，有些分析是有组织政治敏感性的。比如某个团队的指标不好看，人类分析师会巧妙调整呈现方式，AI 完全没有这层意识——它可能直接把最难看的数据怼在第一页。\n\n 第二层：企业数据的\"暗知识\"太多\n\n\n假设 AI 搞清楚了要分析什么（虽然很难），接下来它要取数。这一步同样是地雷阵。\n\n企业数据不像公开数据集那么规整。\"DAU\"这个词，在不同业务线可能有完全不同的定义；同一张表的同一个字段，去年和今年的口径可能已经变了；有些数据是 T+1 的，有些是实时的；有些表看起来能 join，但时间窗口对不上。\n\n这些\"暗知识\"散落在各种文档里，散落在老员工的脑子里，散落在某个群聊的某条消息里。AI 哪怕把整个数仓的 schema 看一遍，也搞不定这些。\n\n最隐蔽的坑是：AI 算出来的数字看起来\"合理\"，但其实是错的。你不仔细核对根本发现不了。\n\n 第三层：没人敢为 AI 的结论负责\n\n这是最容易被忽略但最致命的问题。\n\nAI 不承担任何错误后果。如果它的分析结论导致了一个错误的业务决策，谁来负责？答案是——看这份报告并且签字确认的那个人。\n\n但问题是，如果分析师看不透 AI 的分析过程（用了什么数据、做了什么假设、选了什么口径），他怎么敢签字？怎么敢在周会上把 AI 的结论当自己的结论讲出来？\n\n信任不是喊出来的，是靠一次次验证建立的。初期用户会逐行核对 AI 的每个数字，后期可能只抽查关键节点。产品必须支持这种\"信任度逐步上升\"的使用模式。\n\n 第四层：AI 会写报告，但不解决问题\n\nAI 写流畅的文本是强项，但数据分析的最终交付物不是一篇漂亮的文章，而是决策建议。\n\n好的分析师会把技术语言翻译成业务语言，会预判领导的追问提前准备好 drilldown，会明确区分\"我们确定的\"和\"我们猜测的\"，最终给出带优先级的 action items。\n\nAI 产出的报告呢？通常是\"看起来很专业但不解决问题\"——数据都对，图表都漂亮，但你看完之后还是不知道该干嘛。\n\n\n\n 两个根因：把问题想透\n\n把上面四层难点翻来覆去想了几遍之后，我觉得可以归结为两个根因：\n\n第一，隐性知识没有显性化。\n\n决策上下文（为谁分析、服务什么决策）、数据暗知识（指标口径、表关系、数据潜规则）、受众认知（决策者的偏好和关注点）——这些知识全都是隐性的、动态的、组织特有的。它们不是 AI 通过预训练能获得的通用知识，必须通过某种机制\"喂\"给 AI。\n\n第二，责任机制没有建立。\n\nAI 不负责，人没信息。解决这个矛盾不是靠\"让 AI 更准\"（这在短期内不现实），而是靠让人能快速、低成本地验证 AI 的产出。\n\n一句话总结：隐性知识的缺失让 AI 难以做对，责任机制的缺位让人难以信任。 这两个根因加在一起，才是 AI 做数据分析最大的障碍。\n\n这也意味着，突破口不在\"调模型\"，而在\"建基础设施\"——把隐性知识变成 AI 可消费的结构化资产，把分析过程变成人可审计的透明链路。\n\n\n\n 我的方案构想：一个\"会成长\"的分析画布\n\n\n\n想清楚问题之后，我脑子里逐渐浮现出一个产品形态。它有一个核心设计理念：产品不\"升级\"，而是\"成长\"。\n\n什么意思呢？从第一天起，产品的交互框架就是终态。变化的不是界面，而是每个环节上\"AI 自己干\"和\"等人确认\"的比例——用的人越多、积累的知识越多，AI 能自主完成的就越多。人的参与度下降不是产品强制的，而是用户基于信任主动放手的。\n\n 为什么是\"画布\"而不是\"对话框\"？\n\n我认真对比过三种形态：\n\n| 形态 | 好处 | 致命伤 |\n||||\n| 纯对话（ChatBI） | 上手简单 | 过程不可见、出错要从头来、没法审计 |\n| 传统 BI 看板 | 结构化强 | 不灵活，只能看预设的维度 |\n| 分析画布 + Chat | 过程透明、可分叉、可审计 | 上手成本稍高（但目标用户是分析师，OK的） |\n\n画布的核心隐喻是一棵分析树——从命题出发，拆解为子问题，每个子问题对应\"取数→分析→结论\"的链路，最终汇聚为综合结论。树上的每个节点都是一张可交互的卡片，用颜色标记状态：🟡 AI 草稿、🟢 人已确认、🔵 人已修改。\n\n理想情况下，随着时间推移，画布上的黄色越来越少，绿色越来越多。这本身就是人机协作在进化的可视化证据。\n\n 五个让这件事成立的核心机制\n\n光有画布不够，我设计了五个互相咬合的机制来解决前面提到的两个根因。\n\n机制一：结构化 Brief——把\"模糊需求\"变成\"清晰任务\"。\n\n每次分析的第一步不是开干，而是先填一张 Brief：谁要看、什么场景、关注哪些指标、要挖多深、是否敏感。初期人填、AI 补全建议；后期 AI 根据历史模式自动生成，人只需扫一眼确认。每次 Brief 的填写和修改自动沉淀，下次类似命题 AI 直接调取历史模板。\n\n机制二：活的数据语义层——让\"暗知识\"在使用中自然生长。\n\n这不是传统那种写完就没人维护的数据字典，而是一个用→问→记的活循环：AI 取数时先查语义层；查不到就发起结构化追问（不是空泛的\"请确认\"，而是给出具体选项和历史统计）；用户回答后自动写入语义层，下次不再追问。用得越多，追问越少，AI 越自主。\n\n机制三：X 光模式——让每一步都能被\"透视\"。\n\n每张卡片都支持渐进式展开。L1 一句话摘要（快速判断合理性），L2 分析逻辑（为什么选这个方法），L3 底层数据（SQL、中间表），L4 自动校验结果。用户根据自己当前的信任程度选择看多深。分享结论时，不是分享一张图，而是分享整棵分析树的只读快照——接收者可以自己展开 X 光查看完整链路。\n\n机制四：置信度系统——让\"该不该人工审\"有据可依。\n\n每个结论卡片都有一个置信度分数，基于口径匹配度、数据质量、方法成熟度、历史验证度来计算。高置信度自动通过，中等的等用户确认，低的强制人工审核。关键是阈值用户可调——信任度高的老用户可以把\"自动通过\"的门槛调低。这就是\"产品形态不变，人的参与自然减少\"的核心引擎。\n\n机制五：反馈飞轮——每次人的修改都让系统变聪明。\n\n\n\n人改了 Brief，沉淀到场景库；改了 SQL，沉淀到语义层；改了分析方法，沉淀到模板库；改了结论措辞，沉淀到受众画像库。用户连续 N 次确认同类型卡片无修改，该类型的自动通过阈值就自动降低。每次分析完成后还会自动生成复盘卡片——对比 AI 初版和人修改后的终版，高亮差异，帮系统持续学习。\n\n\n\n 人机比例会怎么演进？\n\n如果上面这些机制都跑起来了，我大致估了一下人机比例的变化趋势：\n\n| 阶段 | 时间 | 人工参与度 | 状态描述 |\n|||||\n| 冷启动 | 01 月 | 80% | AI 主要打下手，人全程把关 |\n| 知识积累 | 12 月 | 50% | 飞轮转起来，常规分析 AI 基本能搞定 |\n| 信任建立 | 23 月 | 25% | AI 主导大部分分析，人只审关键节点 |\n| 成熟期 | 3 月+ | 12% | AI 是分析中枢，人只在新场景和重大决策时介入 |\n\n从 80% 降到 12%，靠的不是模型升级，而是知识积累和信任建立。这才是我觉得最有意思的地方。\n\n\n\n 写在最后\n\n回到最初那个问题——如何让 AI 做好数据分析？\n\n我的答案可能和很多人的直觉不一样：重点不是让模型更聪明，而是帮它补上它天然缺失的两样东西——组织的隐性知识，和人机之间的信任机制。\n\n前者让 AI 有可能做对，后者让人有勇气信任它。两件事都需要时间来\"养\"，不是上线第一天就能解决的。这也是为什么我把这个产品叫做\"会成长的分析画布\"——它不是一个静态的工具，而是一个和用户共同进化的系统。\n\n说到底，人和 AI 做数据分析的理想关系，不是\"替代\"，也不应该停留在\"辅助\"。它应该是一种渐进的共生——AI 在使用中学习组织的知识，人在验证中建立对 AI 的信任，两边螺旋上升，最终到达一个人单独做到不了、AI 单独也做不到的地方。\n\n那个地方，才是 AI Native 数据分析真正的样子。\n\n\n\n本文基于作者与 AI 的多轮对谈整理而成。文中的产品方案是概念性思考，旨在提供一种看待 AI + 数据分析的新角度。如果你也在做类似的事情，欢迎交流。",
      "summary": "",
      "date_published": "2026-04-25T00:00:00.000Z",
      "tags": [
        "数据分析",
        "AI"
      ]
    }
  ]
}