推荐这两个模型，Liquid AI 的新 encoder。 小参数下匹敌大模型质量——长文本 CPU 推理比 ModernBERT 快了数倍。 Liquid AI 在 7 月 28 日发布了两个新的 encoder 模型——LFM2.5-Encoder-230M 和 350M。核心卖点：在小参数下匹敌大模型的质量，上下文 8192 token 且延迟随输入长度增长缓慢，CPU 上比 ModernBERT-base 快约 3.7 倍。 架构 两个 encoder 从 LFM2 解码器主干初始化，然后做三步改造：双向注意力掩码（每个 token 看两边）、非因果短卷积（对称 padding）、30% token 的掩码语言建模训练。 两阶段训练：先用 1024 token 上下文做大语料 MLM，再扩展到 8192 token 强化事实、法律和多语言能力。 Benchmark 在 GLUE + SuperGLUE + 多语言分类共 17 个任务上，350M 版本排 14 个模型中的第 4 名，前 3 名都更大（最大一个 3.5B，近 10 倍参数）。230M 版本击败了 ModernBERT-base 和所有 EuroBERT 模型，参数量更小。 CPU 推理速度 最大的优势在 CPU 上。8192 token 输入时，ModernBERT-base 一次前向约 90 秒，LFM2.5-Encoder-230M 约 28 秒——约 3.7 倍快。这意味着你可以在笔记本 CPU 上 30 秒内扫描完一份完整合同、转录文本或长客服线程。 GPU 上的优势在长上下文时同样存在：短输入（<1000 token）ModernBERT 领先，长输入 LFM2.5-Encoders 反超。 实际用途 附带了 5 个 CPU-only 的 HuggingFace Space demo：零样本 prompt 路由、零样本策略检查、拼写纠正、40 种 PII 检测、掩码扩散文本生成（迭代 unmask 而非从左到右生成）。 两个模型都是开放权重，支持 transformers + Flash Attention 2。 模型： 博客： #Encoder# #CPUInference# #ONNX#

DeepSeek V4.1 Flash 为 552B 参数的 MoE 模型，采用了全新的 Causal-Encoder-Decoder 结构，输入和输出不对称，输入激活只有 8B，输出激活 16B，成本显著低于已知的同尺寸模型。同时，V4.1 Flash 还采用了新的预训练方式、经过了更大规模的强化学习后训练，在基准测试中，成功超越了包括 DeepSeek V4 Pro 在内的一众旗舰模型的智能水平。

在外行大血空眼里：2022年年底，ChatGPT横空出世，宇宙大爆炸。 在我们这些人眼里： 2017年发布transformer，我们一群人在跟着看，看不懂也想不明白，但知道这东西比RNN和LSTM强得多； 2018年发布BERT，Google狂妄至极，全世界都在训练BERT、蒸馏BERT、魔改BERT，OpenAI当时在做decoder only的GPT， 2018年之后很长一段时间，有公司羞辱性地问PhD，“来，跟我讲讲，为什么BERT encoder only是唯一正确道路，为什么GPT这种decoder only是死路一条” 2019年，BERT已经深刻改变世界，Google已经骄傲宣布所有搜索结果都是BERT indexing和sorting的结果，全世界每秒钟调用xxx次BERT，Google震撼发布T5 model，直接把OpenAI甩开身位， 2020年，GPT-3横空出世，当日登顶github trending（一个markdown说明书，没有任何模型，完全闭源，当天党哥全球第三，和GPT-3同框），全世界看了OpenAI的视频demo，彻底炸裂，SQuAD被刷到顶， 2021年，Stanford开始酝酿foundation model（基础模型），代替以前BERT、GPT、transformer这些概念，计划一统江湖，开启新时代。foundation model几乎是一个极其伟大的宣言，告诉整个世界，NLP时代要迎来技术爆发了， 2022年，GPT-3.5 Turbo训练完了，OpenAI发现GPT-3的模式挺好，于是随手糊了一个前端和infra的小玩具，给大家注册玩玩，随便起了一个名字，叫ChatGPT。

千万别拿我和张雪峰这个大傻逼作对比。 网友：我想学AI相关的专业，我对AI很感兴趣，请问我应该选计算机还是数学？ 我：你一定要选计算机，先把python和数据结构基础打好， 然后从deep learning这门课开始学，可以在家配置一个nvidia GPU的笔记本或者台式机，或者用google colab，先从最简单的 CNN 开始训练，找一个dataset，自己安装好pytorch和cuda、cudnn，抄一个经典CNN model，训练你的第一个神经网络， 然后可以学习transformer，学习encoder only的BERT，学习decoder only的GPT模型，从minGPT开始，训练你的最小版本的GPT模型， 如果你对训练模型感兴趣，可以读个PhD，如果你的inference感兴趣，可以多花点时间看cuda，简单学习一下nvidia tensor core architecture，可以了解GPT后续的模型的架构， 如果你对inference感兴趣，你也可以直接看vllm的架构，读里面的代码，理解vllm是如何load一个用pytorch训练好的LLM模型， 如果你对AI Agent感兴趣，可以从ReAct Agent开始看，然后看SWE Agent，知道一个Agent是如何抽象出来的，如何调用function call，如何自己做reasoning，如何把一个软件开发的任务用agentical的方式拆分和执行的， 然后你可以看codex的架构，看看codex是如何设计memory、auto compact、multi agent、background task这些现代coding Agent功能的。 张雪峰（下面视频中可以找到原话）： 孩子，你一定要学数学，数学学好了可以转互联网、AI、科技、半导体、金融所有专业，数学是一切专业之母，所有专业的老祖宗！ 孩子，deepseek就是一群纯数学博士造出来的，这些人天天研究数学，就把deepseek造出来了！ 孩子，AI本质就是数学建模，就是一个个自变量，你只有研究数学，一直读到数学博士，才能把这些数学建模研究明白，计算机毕业生是永远研究不明白AI的！ 我的结论是，鼓吹“数学万能论”、“数学是一切专业的老祖宗”、“只有数学博士才能研究AI”的张雪峰和他们的粉丝，都是彻彻底底的大傻逼。

魔法! DeepSeekV4 上下文内存压缩到1/10! 大家都知道 DeepSeekV4 是支持1M上下文的, 而且经过了极度优化, 如果要真的用到1M上下文, 显存占用只需要10G左右, (对比之下 DeepSeek-V3.2 大概需要84G显存). 然后我刚看到了FlashMemory这个论文, 直接能把显存占用压到 1.3GB! 甚至输出效果不降反升! 哥们你骗兄弟可以, 骗自己就没意思了, 真的吗? 压缩后反而性能上升? 我赶紧看了论文细节: 咱们先复习一下传统做法: 模型每吐出一个字，都要把之前的几十万字重新看一遍(这就是全局注意力). FlashMemory 的做法是: 预测未来需要什么, 它内置了一个神经内存索引器（Neural Memory Indexer, 其实就是个小模型了），能够主动预判接下来生成内容时需要用到历史文本里的哪些片段. 然后预先准备好这些片段, 接下来只要做到命中率超高, 那么这个提升就绝对有效. 即它的假设是, KVCache里面的东西并不是生成每个字的时候全都需要的, 只需要按需提前加载即可. 很像做作业的时候, 把参考资料摊满桌子, 然后优化了一下就是把参考资料需要用到的部分直接拍照, 用的时候看照片就行了. 那么听上去很简单, 但实际的难点在于, 训练一个专用的索引器小模型, 需要把 DeepSeek-V4模型加载到显存里一起炼. 相当耗费算力. 于是这篇论文第二个亮点来了, 它搞了个解耦训练. 他们把这个索引器当成一个标准的"双编码器（Dual-encoder，类似做搜索推荐的模型）"来单独训练. 在这个过程中，根本不需要把庞大的 DeepSeek-V4 基座模型加载到显存中. 这让训练成本断崖式下降，且兼容标准的检索（Retrieval）训练框架. (简单来讲就是它是通用方法训练的, 通过query预测需要检索哪些长句子. 所以其实是个通用模型) 听上去靠谱, 那也只是显存占用少了, 怎么就性能还提高了呢? 答案是注意力降噪. 因为每次只提取和当前生成最相关的记忆块（Chunks）放入显存，模型在运算时就看不见那些无关的冗余信息了.天然地起到了一种"去噪"作用，这也是为什么显存占用少了，模型准确率反而略微提升的原因.官方测试在长文本评测集（如 LongBench-v2 等）上的准确率平均最终提升了 0.6%. (其实还有数据如何逐出显存和如何预测数据实现预加载, 这部分也很棒, 很有启发性. 建议看原论文, 篇幅原因写不下了) 论文地址: 项目地址: #FlashMemory# #DeepSeekV4# #FlashMemoryDeepseekV4#

翻了下 claude code version 191 的源码，感觉从技术角度看，Anthropic 这个反蒸馏机制设计还是挺精妙的。 Claude Code 有段提示词是这样。 return `Today${n}s date is ${r}.`; 他对这句做了隐写，用肉眼分不出的字符，把系统时区和代理端点身份偷偷编码进了系统提示词。 触发条件是当你设了第三方中转 ANTHROPIC_BASE_URL 且不是 时。 所以如果你是官方直连用户，则并不会受到影响。也就是说最近的封号潮与此无关。 它编码了 3 个 bit，来自两个独立维度（时区 1 bit + 撇号 2 bit）： 1）时区，在 Asia/Shanghai 或 Asia/Urumqi 时，日期分隔符从 2026-06-30 偷偷变成 2026/06/30 2）那个撇号 ' 有四种写法，人眼基本看不出区别。 - ' (U+0027 普通)，普通第三方端点 - ' (U+2019)，命中"域名白名单" - ʼ (U+02BC)，命中"国产大模型关键词" - ʹ (U+02B9)，域名 + 实验室都命中 这三个维度是独立编码的。哪怕你的中转域名不在白名单、也不含关键词，只要系统时区是上海/乌鲁木齐，分隔符照样变斜杠——也就是"中国时区 + 任意第三方端点"的用户全员会被打上时区这一维的标记。 匹配逻辑是这样。域名是后缀匹配（host === d || host.endsWith("." + d)），白名单第一个就是 cn，所以任何 .cn 结尾的 host 一网打尽，不是逐个域名去列；关键词是子串包含（host.includes(kw)），host 里只要出现 deepseek 字样就命中，不用精确匹配；时区取的是系统时区（Intl…resolvedOptions().timeZone），不是 IP 地理位置。 更骚的是反混淆，两份名单用 XOR(key=91)+ base64 藏起来，专门躲 strings。解码就是 base64 decode 之后逐字节异或 91，源码里那个 LKi 去混淆后长这样： ```js // 源码里的解码器（去混淆版，就是 LKi） const decode = (b64) => [...Buffer.from(b64, "base64")] .map((byte) => String.fromCharCode(byte ^ 91)) // key = 91 .join("") .split(","); // 逆运算就是打包时的编码器 const encode = (list) => Buffer.from([...list.join(",")].map((c) => c.charCodeAt(0) ^ 91)).toString("base64"); encode(["deepseek", "zhipu"]); // → "Pz4+Kyg+PjB3ITMyKy4=" decode("Pz4+Kyg+PjB3ITMyKy4="); // → ["deepseek", "zhipu"] // 拿真名单开头验一下，key=91 对得上 decode("Pz4+Kyg+PjB3NjQ0NSgzNC93"); // → ["deepseek", "moonshot", ...] ``` 147 个域名白名单:".cn" 顶级域、字节/阿里/百度/网易/快手、 外加一大票 Claude 中转站(anyrouter、88code、yunwu、aihubmix、dmxapi…) 11 个实验室关键词:deepseek / zhipu / moonshot / minimax / stepfun / baichuan / 01ai / dashscope / volces … 选「今天的日期」这句话做载体也很鸡贼。这个标记藏在 system prompt 正文里，不是 HTTP header、也不是 metadata。中转站一般会重写、过滤 header，但几乎没人会去动日期这类的自然语言，所以这是个洗 header 洗不掉的水印。而且 currentDate 是 user context 里和 claudeMd、userEmail 并列的字段，每个请求必带，标记 100% 稳定出现；撇号和分隔符的变化又语义无损，模型读起来一模一样，用户 diff 也基本看不出，隐蔽性拉满。 证据是怎么闭环的，这才是题眼。标记跟着请求走，当一个中转站或蒸馏管道最终回连 Anthropic 官方 API 转售 Claude 时，这条请求带着标记又流回了 Anthropic 自己的服务器。 于是 Anthropic 在自己的日志里就能读到：这条"直连我"的请求，日期是 2026/06/30（斜杠 = 中国时区）+ 撇号是 ʹ（U+02B9 = 域名和 deepseek 关键词都命中），铁证——源头是一个中国时区、配了国产大模型中转的客户端。 它不需要主动探测，让流量自己招供，只要请求最终回到 Anthropic，身份就自证了。这样就能清楚地知道哪些渠道流向了中国、被中转站转售或被大厂蒸馏，并且留下充足证据。 想自己验的话，逻辑都在 cli.js（2.1.191，混淆名每版会变）：检测函数 jqd()（:245688）→ 选字符 Wqd()（:245701）→ 拼日期 MKi()（:245707）；gate 是 Yfn()（:102664）；落点在 currentDate: MKi(eHe())（:250252）；XOR 名单解码器 LKi()，key = 91。

AWS 资深专家解决方案架构师 Daniel Abib 在官方博客里算了一笔账：同步调用时，Lambda 的计费时长几乎等于 agent 思考的时长，等待本身在按全量计算计费。 《在无服务器流水线中异步调用 Amazon Bedrock AgentCore agent 的模式》 在无服务器流水线里异步调用 Amazon Bedrock AgentCore agent，可以消除你的 AI agent 处理请求期间的空转计算成本。一个常见的例子是文档校验：在房地产融资的后台办公室里，agent 可以读取房产记录或贷款合同，推理信息是否完整、一致，然后返回一个下游步骤据此行动的结论。Amazon Bedrock AgentCore 提供了一个平台，让你能用任意框架或模型大规模地构建、连接和优化 agent。 这类 agent 带来一个传统流水线步骤没有的特性：它们在回答之前要思考一会儿。思考多久取决于提示词、模型和文档，但很少是即时的，而这个延迟改变了你调用它的方式。最常见的首版实现是用一个计算服务（比如 AWS Lambda 函数）调用 agent 并等待响应。函数等待期间什么都不做，但它仍在运行，每一秒都在计费。 值得看清成本到底落在哪里，因为调用的两侧计费方式不同。Amazon Bedrock AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）采用基于消耗的计费模型，agent 空闲时不收 CPU 费用。例如，在等待大语言模型生成响应、或等待工具或 Model Context Protocol（MCP）调用返回的这段时间里，你只按内存计费，不按 CPU 计费。调用 agent 的那个计算服务没有这种特性。发出同步调用的 Lambda 函数、容器或 Amazon EC2 实例会一直阻塞，在 agent 响应之前始终持有（并支付）完整的计算配额。所以浪费不在 agent 一侧，而在调用方——它挂在一个打开的连接上空转。 这就让调用方的成本跟着 agent 的运行时间走。阻塞在 agent 上的函数，计费时长几乎等于整个处理时间；而启动 agent 后立即返回的函数，只按短暂的派发计费。解法是在等待期间释放调用方的计算资源，等 agent 出了结果再恢复流水线。本文展示三种做到这一点的模式（task-token 回调、直接服务集成、durable function），并与阻塞式反模式对比。 示例流水线 为了让各模式在同等条件下比较，我们把每个模式都跑在同一条流水线上，只更换调用 agent 的那一步。这条流水线是一个刻意简单、虚构的场景（房地产融资文档校验），选它只是为了把编排讲清楚。它不是本文的重点，它代表任何先调用 agent（或其他慢服务）、再对结果采取行动的流程，你可以把自家用例代入。 流水线有五个阶段： 1. Extract：一个 Lambda 函数对文档做 OCR 和文本提取。（提取是模拟的，所以场景不需要真实文档。） 2. Identify：一个 Lambda 函数对文档分类并设置路由标志（shouldOrganize、shouldValidate）。 3. Route：一个 Choice 状态根据这些标志决定流程走向。 4. Organize and Validate：一个 Parallel 状态在组织文档的同时，让 Amazon Bedrock AgentCore agent 在另一个分支里做校验。这个 Validate 分支是各模式之间唯一变化的部分。 5. Result：一个 Lambda 函数处理 agent 的结论，决定下一步动作（批准，或退回修改）。 图示如下：水平流程依次是 Start、Extract、Identify、Route（Choice）、并行的 Organize-and-Validate 阶段、Result、End，Validate 分支被标为可更换，图例列出了它的四种实现方式：阻塞反模式、模式 1（task token）、模式 2（直接集成）、模式 3（durable function）。流水线本身在每种情况下保持不变，只有 Validate 分支被换掉来演示各自的调用模式。 同一个 Amazon Bedrock AgentCore agent 服务全部四种情况。agent 检查每次调用并选择如何响应：如果收到 AWS Step Functions 的 task token，就在完成时唤醒那个执行；如果收到 durable function 的 callback ID，就唤醒那个 durable function；两者都没收到，就直接在响应里返回结论。这意味着你可以更换编排模式，而不必修改或重新部署 agent。 agent 如何不阻塞调用方就把控制权交回来 机制是 agent 的 action group 里的一个"归还控制权"动作。agent 推理结束后，调用一个 Lambda，把结果和 task token 发回 Step Functions。（后面的模式 2 会让 Step Functions 直接与 AgentCore 集成，完全省掉这个 Lambda。） 下面这段代码是这个 Lambda 的核心： The tool the agent calls once it reaches a verdict @tool def conclude_validation(approved: bool, issues: list, summary: str) -> str: verdict = {"approved": approved, "issues": issues, "summary": summary, "source": "agentcore"} # A Step Functions task token was passed: resume that execution if task_token: sfn.send_task_success(taskToken=task_token, output=json.dumps(verdict)) return "Step Functions resumed." # A durable-function callback ID was passed: resume the durable function if callback_id: lambda_client.send_durable_execution_callback_success( CallbackId=callback_id, Result=json.dumps(verdict).encode("utf-8")) return "Durable function resumed." # Neither was passed: this is a synchronous call, return the verdict inline return "Verdict recorded." 入口函数根据同样的信号决定在后台跑还是同步跑： @app.async_task async def validate_document_async(prompt, document, extracted_text): # Background work; conclude_validation fires the right callback when done agent = build_agent() await agent.invoke_async(message(prompt, document, extracted_text)) @app.entrypoint async def handler(event): task_token = event.get("taskToken") # passed by the task-token pattern callback_id = event.get("callbackId") # passed by the durable-function pattern # Asynchronous: start the work and return "accepted" right away if task_token or callback_id: asyncio.create_task(validate_document_async(...)) return {"status": "accepted"} # Synchronous: run now and return the verdict in the response agent = build_agent() await agent.invoke_async(message(...)) return verdict agent 就位之后，本文剩下的部分聚焦于调用它的四种方式。代码和基础设施定义都是示例中的摘录，用来演示每种模式。 调用 agent：四种方式 先讲阻塞式反模式以确立基准成本，再展示避开它的三个模式。 阻塞式反模式 最直接的实现：在同一个 Lambda 函数里调用 agent 并等待答案。它能用，而且实现简单——这正是它如此常见的原因——但函数在 agent 思考的整个期间一直活着。 // The Lambda function blocks here until the agent responds const response = await agentcore.send( new InvokeAgentRuntimeCommand({ agentRuntimeArn: AGENT_RUNTIME_ARN, payload: new TextEncoder().encode(JSON.stringify(payload)), runtimeSessionId: sessionId, }) ); // The function stays alive and billed for the entire time the agent is thinking. 函数的计费时长最终大约等于 agent 的处理时间。后面三个模式消除这段空闲成本，各自做出不同的取舍。特别是模式 2 使用 Step Functions 对 AgentCore Harness (InvokeHarness) 的优化集成，完全去掉 Lambda。 模式 1：task-token 回调 + 派发函数 这个模式在路径里保留一个 Lambda 做自定义逻辑，但去掉空闲成本。Step Functions 用 waitForTaskToken 集成调用这个函数——传入一个 task token 后暂停执行。函数用这个 token 启动 agent，然后在几秒内返回。执行保持暂停，不产生任何计算计费，直到 agent 用这个 token 调用 SendTaskSuccess 恢复它。 // Start the agent, pass the task token, and return without waiting const response = await agentcore.send( new InvokeAgentRuntimeCommand({ agentRuntimeArn: AGENT_RUNTIME_ARN, payload: new TextEncoder().encode(JSON.stringify({ ...payload, taskToken })), runtimeSessionId: sessionId, }) ); // Returning here does not complete the step. Step Functions stays paused until // the agent calls SendTaskSuccess with this task token. return { dispatched: true }; 对应的状态从上下文取出 token，并设置超时和心跳作为安全网——这样沉默的 agent 会让执行干净地失败，而不是无限期停在那里： "ValidateDispatch": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken", "Parameters": { "FunctionName": "${ValidateDispatcherFunctionArn}", "Payload": { "taskToken.$": "$$.Task.Token", "document.$": "$.document", "extractedText.$": "$.extract.extractedText", "executionId.$": "$$.Execution.Id" } }, "TimeoutSeconds": 120, "HeartbeatSeconds": 60, "Next": "AgentCoreValidation" } 成本。 Lambda 函数仍然会跑，但只跑到启动 agent 并返回为止：几秒钟，无论 agent 之后要跑多久。你只为这次短暂派发付费，不为等待付费——因为函数在 agent 干活时已经关掉了。等待由暂停的 Step Functions 执行承担，它不为空闲计算计费。这是与阻塞版本的关键区别：阻塞版本里函数的计费时间跟着 agent 的处理时间走。 模式 2：直接服务集成 当你不需要围绕 agent 调用写自定义代码时，可以去掉派发函数，让 Lambda 完全离开路径。Step Functions 可以通过 AWS SDK 服务集成直接调用 Amazon Bedrock AgentCore，所以 agent 的响应直接流入下一个状态。Validate 分支于是变成单个 Task 状态： "ValidateDirect": { "Type": "Task", "Resource": "arn:aws:states:::aws-sdk:bedrockagentcore:invokeAgentRuntime", "Parameters": { "AgentRuntimeArn": "${AgentRuntimeArn}", "RuntimeSessionId.$": "States.Hash($$.Execution.Id, 'SHA-256')", "Payload.$": "States.JsonToString($.prep.agentInput)" }, "ResultSelector": { "raw.$": "$.Response" }, "TimeoutSeconds": 120, "Next": "ParseVerdict" } 成本。 路径里没有 Lambda，所以没有空闲的 Lambda 计算可付。Step Functions 承担等待，Standard 工作流按状态转换计费而不是按等待时长计费——处理期间的实质成本只有 agent 本身。 模式 3：Lambda durable function 如果你更愿意用代码而不是状态机来表达编排，Lambda durable function 给你同样的成本行为。用 @aws/durable-execution-sdk-js SDK，流水线阶段变成 context.step 调用，并行工作变成 context.parallel，等待 agent 变成 context.waitForCallback。等待期间函数挂起，不计计算费。agent 用 SendDurableExecutionCallbackSuccess 恢复它。 // Suspend the function until the agent calls back const result = await ctx.waitForCallback( "validate-agentcore", async (callbackId) => dispatchAgentCore(callbackId, document, extractedText, executionId), { timeout: { seconds: 120 } } ); 成本。 一个函数承载整条流水线，但挂起等待 agent 期间不按计算计费。你只为挂起之间短暂爆发的那几次执行付费——与 task-token 模式相同的经济性——而不是为等待付费。 测量差异 重点不是某个具体数字。agent 的运行时间随提示词、模型和文档变化。重要的是 task-token 模式里两个值之间的关系：Validate 状态活跃了多久，对比派发函数实际被计费了多久。我们测试中的单次运行让这个关系可见： Step Functions, ValidateDispatch state Returned (TaskSubmitted): 14:08:19 <- the function returned and shut down Resumed (TaskSucceeded): 14:08:34 <- the agent woke the execution State active ........ 19.6s Lambda, dispatcher function (CloudWatch REPORT) Billed duration ..... 4.8s Result: the state was active for 19.6s, but the function was billed for 4.8s. The ~14.8s in between is wait time with no Lambda function running. 在 Step Functions 的事件历史里也能看到同样的事：task-token 模式下，TaskSubmitted 事件（函数返回）与 TaskSucceeded（agent 恢复流程）之间隔着 agent 的处理时间。同步调用没有这样的间隔。 下表总结了每种模式下 Validate 分支（前面图示中高亮的部分）的实现方式： • 编排器：阻塞＝Step Functions；模式 1＝Step Functions；模式 2＝Step Functions；模式 3＝Lambda（代码） • 路径中的 Lambda：阻塞＝有，存活且计费；模式 1＝有，但提前返回；模式 2＝无；模式 3＝durable function 本身（挂起） • 等待期间的空闲 Lambda 计算：阻塞＝为整个等待付费；模式 1＝无；模式 2＝无；模式 3＝无 • agent 调用周围的自定义代码：阻塞＝有；模式 1＝有；模式 2＝有限（状态转换）；模式 3＝有 • 调用方与 agent 解耦：阻塞＝否；模式 1＝是；模式 2＝否；模式 3＝是 • 相对复杂度：阻塞＝最低；模式 1＝较高（token 和回调的 IAM）；模式 2＝最低；模式 3＝中等（检查点/重放） 读这张表时有一个提醒：总流水线时长不是有用的比较指标，因为它被 agent 自己的推理时间主导——每次运行都不同，而且在所有场景里基本相同。有意义的差异是等待期间你为多少计算付了钱，这由上表和计费时长读数体现。agent 运行时间增长时，派发函数的计费时间保持平稳。上面的数字来自单次运行，把它们当作这个关系的示意而非基准，请测量你自己的负载。 如何选择模式 下表总结了取舍，帮你选择模式： • 调用方成本：阻塞＝整个 agent 处理时间；模式 1＝几秒（仅派发）；模式 2＝零（无 Lambda）；模式 3＝几秒（仅派发） • 集成工作量：阻塞＝低；模式 1＝中高（IAM、心跳、超时）；模式 2＝低（单个 Task 状态）；模式 3＝中等（检查点-重放模型） • 业务逻辑位置：阻塞＝在 Lambda（前 + 后）；模式 1＝在 Lambda（前 + 后）；模式 2＝只在 Amazon States Language（ASL）（内置函数）；模式 3＝在 Lambda（顺序代码） • 最适合：阻塞＝原型、短 agent；模式 1＝自定义前后处理逻辑；模式 2＝纯编排、无自定义代码；模式 3＝单个函数里的复杂异步工作流 最佳实践 防 agent 永不回答。 给每个 waitForTaskToken 状态设置 TimeoutSeconds，让执行以 States.Timeout 失败，而不是无限期挂起。如果你的 agent 发送心跳，也设置 HeartbeatSeconds 以更快发现死掉的 agent。捕获错误并路由到失败或人工审核路径。 重试时使用稳定的会话 ID。 把 sessionId 设为从执行上下文派生的值（比如 Step Functions 执行名），这样重试会恢复同一个 agent 会话，而不是重新开始。task-token 模式里在派发函数中设置；直接集成模式里在 Task 状态参数中设置。 打开 AWS X-Ray。 在 Step Functions 和 Lambda 配置中启用 Tracing: Active。X-Ray 会精确显示 agent 思考了多久、调用方等待了多久，确认你的模式确实在间隔期间释放了计算。 按速度而不是按 agent 的负载来配派发函数。 派发函数只序列化请求并调用端点。256 MB 内存和 30 秒超时通常就够。重活都在 agent 那边。 成本 这些模式会产生 Lambda 计算、Step Functions 状态转换、durable function 执行存储的费用，以及所有方案共有的 Amazon Bedrock AgentCore runtime 和 Amazon Bedrock 模型推理费用。agent 和模型成本在四种情况下相同。架构只改变编排开销，以及阻塞反模式中浪费的空闲 Lambda 计算。当前价格请查看各服务的定价页。 结论 把 AI agent 放进流水线是简单的部分。让它被经济地调用，才是区分原型与生产设计的地方。阻塞在 agent 上的 Lambda 函数实现简单，却在悄悄烧钱——计费时间里的大部分都在等待。本文展示了三种规避方式：需要在路径里保留 Lambda 时用 task-token 回调；最简单的情况用直接服务集成；偏好用代码表达编排时用 durable function。三者由同一个 Amazon Bedrock AgentCore agent 驱动，它会根据被调用方式调整自己的响应。 完整示例（完整的 agent、状态机定义和 durable function）在 GitHub 的 sample-bedrock-agentcore-async-stepfunctions 仓库。想深入的话，可以看 Amazon Bedrock AgentCore 关于异步任务处理的文档。生产部署请使用 Amazon Bedrock Guardrails，对 agent 的输入输出实施负责任 AI 控制。 原文： #Bedrock# #Serverless# #StepFunctions#