周二上午九点，一家中西部社区医院的医疗记录专家 Amy 打开她的编码工作队列——昨天出院的 87 位患者当中，有 41 位的病历还没编完 ICD-10 主诊断码。她清楚自己接下来六小时会做什么：在 EHR 里一页页翻主治医师的自由文本 SOAP 笔记，对照《ICD-10-CM 手册》和 CMS 的 CPT 更新，一个诊断一个诊断地敲进编码字段，同时提防漏掉合并症导致 DRG 分组下调。这正是 2026 年 7 月冲上 Hacker News 首页的开源项目 Screenpipe（YC S26）想解决的核心场景：把 7×24 的本地录屏 + 音频 + 系统无障碍树喂给 AI Agent，让它拥有一个真正"知道你今天看了什么、点了什么、说了什么"的第二大脑。本文基于美国劳工统计局（BLS）最新数据，剖析这场 AI Agent 医疗编码新姿势如何精准命中美国近 20 万医疗记录专家的核心痛点。
一、BLS 数据揭示：19.48 万美国医疗记录专家正被"越堆越多的编码待办"淹没
根据美国劳工统计局 2025 年 8 月 28 日更新的《职业前景手册》（SOC 29-2072），美国医疗记录专家 2024 年在岗约 194,800 人，中位年薪 $50,250（时薪约 $24.16），高于所有职业中位 $49,500。BLS 明确指出该职业 2024–2034 年岗位增长 7%，远超所有职业平均的 3%（much faster than average），十年内增加 13,800 个岗位，年度开放岗位数约 14,200。
BLS 在"Work Environment"里写得直白：这是"少数几种没有直接患者接触"的医疗职业，医疗记录专家一天大部分时间都对着电脑。在"What They Do"里，BLS 列出的核心职责包括"审查病历的时效性、完整性和准确性"、"使用分类系统给患者诊断、操作、医疗服务分配临床编码"、"电子记录数据以便收集、存储、分析、检索和报告"——每一项都是纯桌面的、高认知强度的、极易被打断的工作。
围绕"为什么 AI 医疗记录自动化在 2026 年集中出现"，BLS 数据背后是三大真实痛点：
- 待编码病历持续堆积：BLS 在"Job Outlook"里明确写道，"老龄人口占比上升，慢性病（心脏病、糖尿病等）患病率上升"，直接带来"更多的医疗记录专家需要把患者信息和服务翻译成标准化编码用于保险报销"。DNFB（Discharged Not Final Billed，出院未终结账单）常年压在医院现金流上——每延迟一天编码，账单周转就延迟一天。
- 上下文永远在流失：一份典型病历跨越 SOAP 笔记、影像报告、化验单、护理记录、既往史。医疗记录专家要在多个 EHR 标签页之间来回切换，昨天看过的一个关键既往史今天就得再翻一遍。BLS 强调"细节导向"是这一职业的必备品质，但人的短期记忆并不擅长长时间跨会话的细节保持。
- AI 已在压缩这个职位：BLS 在"Employment"章节亲自写道——"However, the increase in adoption of artificial intelligence (AI)-powered solutions that make the medical coding process more efficient may affect the demand for these workers"（AI 编码工具效率提升可能影响该职业需求）。这是 BLS 罕见地在职业展望里点名 AI 冲击的段落。留在这个职位上的人，越来越需要变成"人+Agent"的组合体，而不是纯手工编码员。
这三个痛点的共同结构——都是"我今天看过的信息，AI 应该已经知道"——正是 Screenpipe 这类"屏幕记忆层"想填补的位置。
二、Screenpipe 是什么：给 AI Agent 装 7×24 屏幕记忆的开源本地系统
Screenpipe 由创始人 Louis Beaumont 于 2024 年开源、2026 年通过 YC S26 加速器发布 Launch HN，是一个跑在 macOS / Windows / 实验性 Linux 上的本地屏幕与音频记录系统。它的核心设计有四层，全部围绕"给 AI Agent 一个可查询的时间线记忆"：
- 事件驱动的智能采样：早期版本靠"连续录像 + 全帧 OCR"，把电脑变成"暖气片"。现在 Screenpipe 监听 app 切换、点击、打字停顿、滚动、闲置回退等事件，只在有意义变化时才把截图与操作系统的**无障碍树（accessibility tree）**在同一时间戳配对存下来。这直接解决了 OCR 数据爆炸与结构丢失两个问题。
- 本地优先存储：所有数据默认写进本地 SQLite + mp4 + md 文件。企业版才允许指定数据落到公司选定的位置。团队自研了一个跑在 Apple MLX / Windows DirectML 上的 AI PII 脱敏模型，本地做敏感信息遮蔽，CPU 占用 <1%、内存 <400 MB。这一点对 HIPAA 场景至关重要。
- AI 友好 API + MCP：在本地
http://127.0.0.1:3030暴露带鉴权的 API 与一个 MCP 服务器。任何支持 MCP 的 Agent（Claude Code、Cursor、Codex、Claude Desktop、Openclaw、Hermes 等）都能像查数据库一样查"用户今天看过的所有病历页"。 - 技术底座：主体用 Rust 写，Apple 侧用 cidre 直连 C API，Windows 侧用 windows-rs，采用 MLX / ONNX 做本地推理。这套栈的意义是：它足够快、足够小，能在诊所里那台老旧 Windows 工位机上安静地跑，而不是需要一台工作站。
许可证方面：Screenpipe 采用自研的 Commercial License——个人非商业、非营利、教育与研究用途免费，商业使用需要授权；License 变更前发布的版本仍以 MIT 保留。这一点在医院采购与信息安全评审时需要提前和法务对齐。
三、AI Agent 医疗编码 4 步工作流：Screenpipe + MCP 怎么用
以 Amy 早上要清那 41 份未编码病历为例，一个组合式 AI Agent 医疗编码工作流大概长这样：
第 1 步 · 本地部署 + 采集范围收窄。Amy 或医院 IT 用 npx screenpipe record 起一份 CLI 或安装桌面版，只对 EHR 相关的应用/窗口/网址加白（Screenpipe 支持按 app / window / URL 过滤，并尊重浏览器隐身模式）。所有截图 + 无障碍树 + 音频落地本地 SQLite，AI PII 模型对姓名、SSN、地址实时脱敏，音频用本地 Parakeet/Whisper 转写。这一步的关键是把"7×24"限定成"7×24 但只在 EHR 里"，绕开 HIPAA 里最敏感的"越权采集"红线。
第 2 步 · 把 Screenpipe 接进 Agent（走 MCP）。在 Claude Code 里执行 claude mcp add --transport http screenpipe http://127.0.0.1:3030/mcp（Cursor / Codex / Claude Desktop 同理）。Agent 从此可以像调用数据库一样问："过去 2 小时我在 EHR 里看过哪些患者的哪些页面？"、"上周三下午我在 87 岁女性 CHF 患者的化验单上停留了多久？"。这一层的价值是把病历上下文从人的短期记忆搬到 Agent 的可查询记忆里。
第 3 步 · Agent 边看边建议编码。当 Amy 在 EHR 里打开一份新出院患者的病历，Agent 通过 Screenpipe 观测到她当前页面的完整无障碍树（含结构化的诊断字段、非结构化 SOAP 段落）。它调用一个本地或云端的编码知识库（如医院自建的 ICD-10-CM / CPT 向量库），实时在侧边栏提示："这份病历里出现 'atrial fibrillation with rapid ventricular response'，建议 I48.91 + I50.9（若合并 acute heart failure）"。Amy 一键接受或改写，Agent 顺手把她的选择写回自己的持续记忆——下次遇到类似模式，Agent 的建议会更贴近 Amy 的编码风格。这一点呼应了 Karpathy 的"LLM 维护的 wiki"理念——Agent 越用越懂这家医院的编码惯例。
第 4 步 · 生成合规审计包。每份已编码病历，Agent 都能从 Screenpipe 的时间线里生成一个可复现的审计包：Amy 什么时候看了哪些字段、Agent 什么时候给了什么建议、她接受还是拒绝、最终提交的编码是什么。这是医院 HIM 部门与外部审计（RAC、CMS）都想要的"决策链路"证据。此前这一层只能靠 EHR 的粗颗粒审计日志，现在有了屏幕层记忆，颗粒度是逐字段、逐次点击级的。
四、真实效果、合规边界与需要提前谈的三件事
从 Screenpipe 官方 Launch HN 描述与开发者社区反馈看，早期采用者常见的三类效果是：编码建议的接受率显著提高（因为 Agent 看得到医生此刻在读的原始上下文，而不是靠事后 API 拉取的结构化字段）、跨会话上下文不再流失（"我昨天在这位患者的化验单里注意到 K+ 3.2，今天 Agent 直接提示"）、以及自动化机会主动浮现（Screenpipe 的企业版本身就以"帮公司发现自动化机会"为卖点——分析一周的屏幕活动，输出"这 7 类重复任务可以让 Agent 接管"）。
但医院场景要落地，有三条底线必须和 IT/HIM/法务谈清楚：
- HIPAA 与最小必要原则：本地存储不是免罪金牌。Screenpipe 的 PII 模型只是脱敏一层，医院仍需评估：屏幕采集是否属于 ePHI 范围？BAA（Business Associate Agreement）如何签？企业版数据落哪里？
- 多用户共享工位：很多医院前台/编码室共用一台工位机。Screenpipe 的"按 app/URL 过滤 + 录制排班（recording schedules）"能力必须先按角色配好，否则一份录像里可能混进不同班次、不同角色的数据。
- 商业授权：医院使用属于商业用途，不适用免费条款。采购之前先和 Screenpipe 商业团队谈许可范围与迁移条款。
一个务实的建议：把 Screenpipe 先跑在 HIM 部门的单一编码工位上做 30 天试点——测三件事，(1) 编码建议接受率与 DRG 分组正确率有没有提升，(2) DNFB 队列平均清空时间有没有下降，(3) 审计包是否能通过内部合规抽检。跑通了再考虑扩到整个编码组。这条路径也符合我们之前写过的AI Agent 记忆层落地方法论："先记，再查，再动作"。
五、FAQ：关于 AI Agent 医疗编码，读者最关心的 5 个问题
Q1：Screenpipe 在诊所里合法吗？
根据美国劳工统计局的说明，医疗记录专家日常工作本身就"必须依法保护患者隐私"。Screenpipe 的本地优先架构 + 可配置的 app/URL 白名单 + 本地 PII 脱敏模型，从技术上提供了合规落地的路径，但合规是流程问题不是技术问题——必须由医院隐私官（Privacy Officer）出具评估、签 BAA、更新 HIM 部门 SOP 之后才能上线。
Q2：Screenpipe 会不会取代医疗记录专家？
BLS 在 Job Outlook 里已经明确写道 AI 编码工具的采用"可能影响该职业需求"，同时也预测该岗位十年增长 7%。研究表明短期内更现实的图景是编码专家从"手动录入"变成"审计 Agent 建议 + 处理疑难病历"——收入结构与 JD 会重写，但岗位不会一夜消失。
Q3：跟直接用 EHR 自带的 AI 编码功能有什么区别？
EHR 自带 AI 编码通常只能看到结构化字段与该 EHR 内的信息。Screenpipe + MCP 的路径看得到编码专家在整个桌面上的完整上下文（多个 EHR 标签页、CMS 网站的最新 CPT 更新、内部 wiki 的编码惯例），并且跨会话、跨 App 保持记忆。两者不冲突，可以叠加。
Q4：本地跑得动吗？会不会拖慢诊所工位机？
Screenpipe 官方数据是本地 PII 模型 CPU <1%、内存 <400 MB，主体用 Rust + MLX/ONNX。对老旧 Windows 工位机也能跑。真正的资源大头是存储——7×24 的屏幕 + 音频原文件会长很快，医院要提前规划本地 NAS 或按班次滚动清理策略。
Q5：跟我们之前介绍过的其他 MCP 工具有什么协同？
Screenpipe 补的是"记忆层"，与之前介绍过的Palmier Pro（MCP 视频剪辑）、MCP ANSI 注入防御这类"动作层" / "安全层" MCP 工具是互补关系。一个成熟的 AI Agent 医疗编码栈通常是：Screenpipe 记忆 + EHR MCP 动作 + 编码知识库 RAG + 审计 MCP 拼装出来的组合。
想追踪更多真实的 AI Agent 医疗与合规用例？订阅 Real Agent Use Cases 免费周刊——每期一位专业人士 + 一个他们真正在用的 Agent。