阅读

1951年，剑桥大学的计算机停机六个月。生理学家Andrew Huxley不得不摇着手摇机械计算器，花了三周多时间求解他和Alan Hodgkin刚建立的方程——那组描述乌贼神经细胞动作电位的方程。为了让曲线拟合实验数据，他们发现必须把某个变量取四次方。当时他们不知道为什么，只知道更简单的版本（比如三次方）拟合效果不够好，而更高次方虽然可能拟合得稍好一些，但额外的复杂性不值得。他们谨慎地提出一个假说：也许膜上有四个带电粒子必须同时到位，门控才能打开。

几十年后，另一个团队找到了相关钾离子通道蛋白的结构，发现它确实由四个相同部件围绕中央孔排列而成。模型在1951年拟合了数据，却帮助预测了它从未被拟合过的蛋白质结构。

ELLIS研究所图宾根分部与图宾根大学的Jakob Macke、Daniel Gedon和Stefan Wahl在2026年11月发表的这篇客座文章中，以这个故事为起点，提出了一个关于AI辅助科学建模的核心论点：仅仅知道四次方能拟合数据是不够的；重要的是知道更简单的版本不工作。一个只把模型递给你的AI系统可以给你答案，但给不了你理解。

他们把科学建模分为三步：构建模型（决定方程的形状和组成部分）、约束模型（调参数以拟合测量数据）、解释模型（问模型对真实系统说了什么）。Hodgkin和Huxley的四粒子假说之所以站得住脚，恰恰是因为他们排除了更低次方的替代方案。如果三次方同样能拟合，就没有理由认为门控有多个运动部件。

文章认为，AI在约束环节进展最大。传统方法只给出一组最佳参数，隐藏了其他同样能拟合数据的组合。模拟推断（SBI）通过大量随机采样和神经网络训练，返回参数的完整概率分布，让研究者看到哪些参数被数据牢牢约束、哪些仍然模糊、哪里需要更多实验。这一方法已被应用于Hodgkin-Huxley模型本身，也用于中子星碰撞定位、宇宙学和结构生物学等领域。

在构建环节，LLM代理现在可以写代码生成候选模型、运行、约束参数、比较输出、修改方程形式，循环往复直到拟合足够好。但文章指出一个关键问题：同一数据上运行两次代理，可能返回两个不同但同样好的模型。只返回其中一个，就像只返回一组最佳参数一样，隐藏了其余可能性。因此作者主张，构建模型应当像约束模型一样处理：要求AI系统返回所有能合理解释数据的模型范围，而非单一最佳拟合。

这引出文章最核心的认识论主张：模型分布才是解释的基础。如果所有存活的模型共享某个特征，数据很可能支持它；如果它们分歧，说明证据薄弱，指向下一个实验该做什么。Hodgkin-Huxley的四粒子假说只有在知道低次方不工作时才有意义——这正是分布信息提供的。

文章承认，到目前为止这些系统主要在重新发现科学家已知模型的任务上测试，对没有已知答案的新问题的证据仍然稀少。但作者认为，随着LLM在研究任务上的能力提升，这一状况会改善。他们引用的证据包括Romera-Paredes等人2024年的工作和Wahl等人2026年的方法。

在解释环节，作者承认这是最难交给AI的一步：我们可以衡量模型拟合数据的程度，但无法衡量它是否带来了对系统的更好理解。他们提出两条路径：一是通过扰动预测来评估AI的理解能力，二是让AI的输出帮助人类科学家更好地理解问题——例如一个设计量子实验的AI系统，不是给出单一设置，而是写出一段生成整族实验设置的短程序，物理学家可以直接读出底层设计原则。

文章最后回到Hodgkin和Huxley的故事：他们花三周摇计算器的工作虽然笨拙，但不是浪费的。模型提供的许多洞见来自创造它的过程；他们理解模型在说什么，是因为他们自己构建了它，知道什么没有工作。AI可以在一个下午完成同样的计算工作，但要提供理解，它需要交付两位科学家缓慢工作所产出的东西：不只是拟合的模型，还有哪些部分被数据钉死、哪些仍然开放、哪些替代方案在过程中失败了、过程中发现了哪些新谜题。

作者以数学家Richard Hamming 1962年的话收束全文：计算的目的是洞见，不是数字。一个科学模型可以提供答案，但提供洞见的是构建它的过程。

企业 AI Agent 需要访问数据湖时，最常见的做法是每个 Agent 各自嵌入 SQL 生成逻辑、表结构知识和连接处理。数据集一旦变化，每个 Agent 都要单独修补；权限散落在各处，没有统一的审计点；接入一张新表通常需要数天的定制开发。AWS 支持北美分拣中心（NASC）网络的工程团队在数千个数据集和多个团队各自构建 AI 助手的现实压力下，选择了另一条路：把数据访问能力集中到一个无状态的 MCP 服务器中，让 Agent 只负责推理和编排，不再关心底层数据如何接入。

这个服务器的核心设计决策是把工具层从 Agent 层中剥离出来。Agent 演化很快，但数据访问模式应该比任何单一 Agent 实现活得更久。具体做法是：每张表对应一个 JSON 元数据文件，记录数据库服务名、表名、业务描述、列级语义（包括类型、自然语言说明和样本值）、加载类型和刷新频率。这个文件被管道拾取后，用 Amazon Titan Text Embeddings 生成向量嵌入，索引到 Amazon Bedrock Knowledge Bases。一旦索引完成，所有已连接的 Agent 都能发现并查询这张表，不需要手动重建索引或重启服务器。

元数据文件里有一个容易忽略但实际关键的字段：business_description_for_the_table。它不只写表的业务含义，还携带引擎特定的查询提示。比如文中示例写道

In Athena SQL, always use date() to wrap string literals when comparing against timestamp columns.

这类提示直接减少了 SQL 生成后的校验失败次数。列级样本值同样重要——Agent 看到 warehouse_id 的样本值是 FC-EAST-07 而非East region facility，生成的 WHERE 子句就会用正确的格式。

架构分为四层，各自独立伸缩：客户端层处理认证和会话状态（Amazon Cognito 验证 JWT，DynamoDB 存储对话历史），MCP 服务器层做查询分析、工具选择和结果编排（FastMCP 框架，Amazon Bedrock 驱动），工具层对接 Athena 和 Redshift 执行 SQL、对接 Knowledge Bases 做语义检索，知识库刷新层负责元数据文件的发现和索引。Fargate 任务是无状态的，会话状态持久化在 DynamoDB 中，所以任务可以随时替换或扩缩而不丢失上下文。

团队还引入了一个可选的上下文映射机制：为特定应用指定它应该关注哪些表。当上下文限定了表范围，MCP 服务器在元数据目录中只搜索这些表，减少噪声、提高 SQL 生成准确率，同时把端到端延迟控制在他们自测的 15 到 20 秒范围内。没有指定上下文时，Agent 搜索所有已索引的表。

安全控制分层实施：MCP 服务器运行在私有子网，不直接暴露于互联网；只有客户端层通过带有 AWS WAF 的公网负载均衡器可以路由请求到它。Athena 查询工具在工具层面强制 SELECT-only，写操作在到达数据湖之前就被拒绝。所有工具调用以结构化 JSON 记录到 Amazon CloudWatch，给安全团队一个跨所有 Agent 和应用的统一审计点。

这套模式的可迁移认识是：当你的 Agent 数量和数据集数量同时增长时，把接入新数据从代码问题变成配置问题，能显著降低边际成本。但它的适用边界同样明确——整个实现深度绑定 AWS 服务栈（ECS Fargate、Athena、Bedrock、DynamoDB），元数据文件的准确性依赖人工维护，描述漂移或过期时的自动处理机制在文中被列为未来计划而非已实现，15 到 20 秒的延迟是团队自测结果而非独立基准。

构建 agent 系统时，一个反复出现的问题是：同一个用户请求到底该归类为什么。Amazon Quick 团队在 2026 年 11 月发表的一篇博客中给出了他们的回答——不是给出唯一答案，而是提供一套让不同答案可以共存并互相切换的词汇。

他们把 agentic 工作拆成四个基本问题：When（什么触发了工作）、What（任务内容是什么）、Who（谁来做）、How（怎么做）。触发器同时回答 When 和 What；agent 回答 Who；能力（capability）回答 How。这个分解本身并不复杂，但它的价值在于：当你有了这四个问题，同一个请求的不同实现路径就不再是互斥的竞争方案，而是同一框架下 confidence contract 的不同刻度。

所谓 confidence contract，是指 agent 保留多少自主权与用户预先固定多少流程之间的比例。Amazon Quick 团队用了一个具体例子来说明：用户说“监控我的 Slack 频道，每天发一份摘要”。这句话至少可以三种方式实现——第一种，一条定时任务加一句指令，让 agent 自己判断怎么做；第二种，用一个 skill 打包明确的格式规则和频道优先级；第三种，用一个 workflow 声明确定性步骤和错误处理。三种都产出每日摘要，区别仅在于 agent 的 latitude 有多大。

这个区分在实践中有一个可操作的推论：一个用户请求“我要一个监控 Slack 并每天发摘要的 agent”，通常不是要创建新 agent 或 workflow，而是给已有 agent 加一个 trigger。Amazon Quick 团队由此把聊天、定时和所谓“自主” agent 合并为同一个 actor——你可以跟它对话、给它排日程、让它编排和检视自己的过去工作。

关于 skill 和 workflow 的关系，他们提出了一对动态概念：crystallization（结晶）和 dissolution（溶解）。一个被充分理解的 skill 可以收紧为 workflow；一个频繁遇到边界情况的 workflow 可以放松回 skill。这个转换由他们的 continuous learning 框架驱动，具体机制在后续文章中展开。

值得注意的边界：这是一套厂商内部提出的词汇表，用于统一其自身产品线的架构讨论。文章没有提供独立采纳证据，也没有对照实验表明这套分类确实降低了构建者的混淆。它的价值目前停留在“一个清晰的归因论证”层面——作者解释了为什么需要共享词汇、这套词汇如何构成、以及它如何改变一个具体请求的归类方式。对于正在构建 agent 系统的读者，这套四问分解和 confidence contract 提供了一个可直接使用的思考框架，但将其视为行业标准仍为时尚早。

Greenlight Financial 的安全运营智能体 Luna 有一个值得注意的设计选择：它不是靠更强大的模型或更多的工具来提升准确率，而是靠记忆。

Luna 是一个分层多智能体系统，Tier 1 处理日常告警的分诊，Tier 2 处理需要多步推理的复杂案例。仅靠 Tier 1，自主解决率停在 83%。Greenlight 报告说，加入记忆层后这个数字超过了 90%。

记忆层分两块。第一块是 30 天滚动窗口的短期记忆：当新告警到来时，Luna 会检查这个模式在过去 30 天是否出现过、当时怎么判定的、是否应该直接放行。Greenlight 举了一个具体例子——某个基础设施角色每周二凌晨三点执行一次计划维护，没有记忆的系统会每周重新标记这个行为，有记忆的系统在第一次解决后就学会了这是预期行为，自动加入白名单。

第二块是长期记忆，存储超出 30 天窗口的语义偏好和解决模板。比如来自某个特定暗网来源的卡有 73% 的误报率，优先去重；或者针对反复出现的案例类型编码的解决模板。

真正驱动准确率从 83% 到 90% 以上的，是连接这两块记忆的案例学习管线。一个 AWS Lambda 函数捕获每次案例解决结果，DynamoDB 存储解决模式并去重。关键规则是：当 Luna 用相同方式解决一个案例三次，它就记录为一个确认模式。然后另一个 Lambda 把这些新学到的东西处理成可操作的上下文，供监督者在推理时消费。这个反馈回路让 Tier 1 的首次通过率持续改善。

Greenlight 把这套做法列为五条经验之一，称之为记忆复利：每个被解决的案例都教会 Luna 一件事——一个新的白名单模式、一个确认的误报来源、一个解决模板。运行六个月后，Luna 积累的组织知识相当于一个新人类分析师需要数月才能建立的经验。

需要指出的是，这些数字全部来自 Greenlight 自报的生产测量，由 AWS 作为平台方发布。文章没有披露分母（同期案例总量是否变化）、没有说明选择效应（复杂案例是否仍依赖人工）、没有前后对比的实验设计。83% 到 90% 以上的提升将 Tier 2 的加入与记忆层的贡献合并报告，无法单独归因于记忆机制本身。

Anthropic研究团队分析了207049次科研会话（2026年8月至9月），覆盖34个学科、7262项研究任务，得出了一个反直觉的结论：科学家把AI用在了AI最能做的地方，而不是他们自己认为最重要的地方。在调查中，研究者将构思与假设生成列为对产出重要研究成果最关键的任务，数据收集排第二；但在实际会话中，数据分析占了Claude约三分之一的用量、Claude Code近一半，而构思仅占Claude会话的4.2%、Claude Code的2.1%。

这一使用模式并非随意选择，而是紧密跟随AI的理论能力。研究团队用Bradley-Terry模型（与象棋等级分同一方法）为每项任务构建能力分数：让语言模型比较任务步骤对，判断哪个AI更能胜任，再聚合为任务级得分。结果显示，能力分数最高的20%任务（如数据可视化、统计检验）获得了研究者时间预期两到四倍的AI用量；能力最低的20%（如纯化反应混合物、参与观察）几乎无人使用。能力分数与三个因素高度相关：任务是否适合强化学习（即能否在计算环境中反复尝试并获得即时反馈），工作是否以认知为主而非物理或人际交互，以及是否存在限制AI使用的监管约束。简言之，科学家似乎在AI最有效的地方使用AI。

基于这些发现，报告构建了三种加速情景。当前能力广泛采纳后，部分领域产出可翻倍（计算机科学约2倍，统计学约2倍）。若AI自动化75%的非物理步骤，计算机科学可达约8倍，但实验科学因物理瓶颈仅达2-3倍。若全部非物理步骤自动化，计算机科学和统计学理论上可达15-16倍，而化学、生物学等仍被约40%的物理时间卡住。这些数字是模型推演而非预测，依赖明确假设：AI每小时成本30美元对比研究者95美元，以及任务互补性导致的瓶颈转移效应。

报告也记录了专用工具正在缩小这一差距。Claude Science（连接多个研究数据库的专用接口）中，构思与假设生成占8%的会话，接近研究者时间占比，是通用Claude的两倍。在生物医学领域，Claude Science上超过80%的任务需要博士级训练，70%以上以高度自主方式执行，远高于Claude的23.7%，也高于Claude Code的64.1%。这暗示通用AI工具的能力边界正在被专用基础设施部分突破。不过需要注意，调查的528名受访者来自主动申请AI研究额度的群体，很可能比一般科学家更重度使用AI；能力分数由语言模型生成，其准确性本身未经独立验证；加速情景假设了完全扩散，而现实中技术采纳通常滞后于能力。

c't杂志记者Jan-Keno Janssen在2026年11月的视频中公布了一系列本地大模型硬件实测数据，核心发现是：决定token生成速度的不是GPU的浮点算力，而是内存的数据传输速率。他用llama.cpp标准工具测试Qwen 3.8-27B（Q4_K_M量化），RTX 4090达到每秒51.1个token，而同一台机器上仅用DDR5-5200内存运行CPU推理时，速度低到肉眼可见地逐字输出——差距约15倍。他明确指出，DDR5-5200的带宽比4090的GDDR6X慢超过12倍，这个比例基本对应了推理速度的差异。

这一机制解释了不同硬件平台在编码代理工作流中的实际取舍。Mac Studio M5 Ultra（256GB统一内存）在token生成阶段与RTX 4090几乎持平，但在prompt processing（读取长代码或文档）阶段不到4090的三分之一：4090读完约4000个token的视频文本只需一秒多，Mac需要约4秒。对纯聊天影响不大，但编码代理需要反复读取代码库和文档，两个阶段的瓶颈分别落在带宽和算力上。AMD RX 9070 XT（920欧元，16GB显存）虽然跑出每秒34.4个token，但Qwen 3.8-27B的权重加上上下文几乎占满显存，实际可用上下文仅约8K token，无法同时支持图像识别和编码代理所需的60K以上上下文——这意味着它能跑benchmark，但难以胜任实际工作。

Janssen给出的实用原则是：选硬件时先看内存带宽，再看容量。24GB或32GB显存的GPU能同时容纳模型权重和足够上下文；统一内存系统建议48GB以上以留出操作系统和其他软件的开销。Intel Arc Pro B70（32GB，当前售价1700欧元以上）生成速度约为4090的一半，但容量充裕且支持ComfyUI图像生成。AMD Strix Halo（128GB统一内存，4000欧元以下）原始生成速度仅每秒13.3个token，但启用投机解码后在代码生成场景可提升至40以上，代码复现场景甚至超过100。所有数据均为作者自测，使用llama.cpp的llama-bench工具在标准参数下获得，未经独立复现。

Agent模拟的资源配置有一个根本矛盾：沙箱内的代码全部由大语言模型生成，运行模式无法预先确定。一个沙箱的生命周期内，往往先经历等待模型响应的静默期，紧接着出现grep命令或文件遍历之类的瞬时尖峰。尖峰的高度取决于模型恰好生成了什么代码，这在配置时是不可知的。

AI数据公司Snorkel此前为每个沙箱估算CPU和内存配额，结果两头不讨好：配额不足时任务中途崩溃，整次运行作废；配额充裕时资源闲置，花费效率低下。Snorkel的AI平台高级经理Rustem Feyzkhanov说，他们需要在不超配的前提下支撑来自领域专家和Agent的各种任务。

Modal提供的弹性突发机制改变了这一局面。沙箱在配置时指定一个基线资源量，运行时可以按需向上扩展CPU或内存。计费规则取实际用量与请求量中的较高者。这意味着Snorkel可以把初始请求调低——因为突发能力兜底了尖峰——而不必再为最坏情况预留余量。Feyzkhanov称，这一变化使他们的沙箱总账单降低了约20%。

目前约10-15%的Snorkel沙箱启用了突发功能，团队仍处于早期采用阶段。但这一机制解决的不只是成本问题。当资源配额不再需要为不可预知的尖峰留余量时，评估结果的可靠性也随之提升——因资源不足而失败的运行减少了，这些失败本身会污染基准测试数据。

Snorkel每月运行数百万次Agent模拟，峰值时段每小时创建数万个沙箱。评估环境需要尽可能接近Agent实际将面对的工作条件：ML Agent需要GPU来训练模型，基础设施Agent可能需要完整的Linux内核。如果环境不真实，就无法区分Agent的失败究竟源于缺少工具还是源于自身能力不足。Feyzkhanov说，Modal的沙箱让他们能在数百万次模拟中复现从多容器基础设施到GPU深度学习环境的复杂系统。