共线部署”（Collocated Deployment）是端侧特有的场景——多个AI模型同时在一台设备上运行，共享有限的算力和内存资源。自动驾驶感知模型（摄像头+激光雷达）座舱语音助手（ASR + LLM + TTS）驾驶员监测（人脸+姿态）车载娱乐的AI推荐这些模型分属不同子系统，但都要抢NPU/GPU/内存。怎么协调？这就是共线部署要解决的问题。

大家好，我是你的AI Infra学习搭子。今天我们来聊一个在LLM推理优化领域非常有意思的技术——Speculative Decoding（投机解码）。如果你觉得大模型生成速度慢、一个字一个字往外蹦太煎熬，那这篇文章一定要看完，因为它讲的就是怎么让大模型"一次蹦好几个字"。

把算法模型里的计算，用尽可能高的效率在硬件上跑出来。为什么需要手写算子？直接用cuBLAS、cuDNN、TensorRT这些通用库不行吗？大部分情况可以，但总有一些通用库覆盖不到的场景业务里的特殊算子（比如BEV视图变换、多模态特征融合）需要和前后算子做fusion（融合），减少kernel launch和内存读写特殊的shape或数据布局，通用库优化不好需要迁移到非NVIDIA平台（比如昇腾、寒

把算法模型里的计算，用尽可能高的效率在硬件上跑出来。为什么需要手写算子？直接用cuBLAS、cuDNN、TensorRT这些通用库不行吗？大部分情况可以，但总有一些通用库覆盖不到的场景业务里的特殊算子（比如BEV视图变换、多模态特征融合）需要和前后算子做fusion（融合），减少kernel launch和内存读写特殊的shape或数据布局，通用库优化不好需要迁移到非NVIDIA平台（比如昇腾、寒

LLM Wiki 的真正价值，不在于单次回答的智能程度，而在于它试图将 LLM 从一个"每次都重来的回答器"升级为一个"越用越值钱的知识运行时"。LLM = 编译器聊天 = 入口Wiki = 产品Graph = 导航Schema = 操作系统Review = 刹车Log = 审计轨迹但它并非没有争议。幻觉回写、治理成本、部分更新等问题决定了它目前的定位是"小规模深度知识工程工具"，而非万能的替代品

许多看似需要"更聪明模型"的问题，实际上只是接口问题——把任务所需的数据纳入上下文，或把完成任务所需的操作封装成工具，原本不可解的任务就可能变得可解。以 Manus 和 OpenClaw 为例，两者的演进本质上都是观察空间和动作空间的扩展。Manus 把深度调研、代码生成和电脑操控三条原本独立的路线合并到同一个 Agent 中；OpenClaw 则通过 WhatsApp、Telegram 等消息渠

许多看似需要"更聪明模型"的问题，实际上只是接口问题——把任务所需的数据纳入上下文，或把完成任务所需的操作封装成工具，原本不可解的任务就可能变得可解。以 Manus 和 OpenClaw 为例，两者的演进本质上都是观察空间和动作空间的扩展。Manus 把深度调研、代码生成和电脑操控三条原本独立的路线合并到同一个 Agent 中；OpenClaw 则通过 WhatsApp、Telegram 等消息渠

本质：Agent = LLM + 上下文 + 工具，是把思考、现场、执行连成闭环的持续运行系统；引擎：ReAct（思考—行动—观察）循环驱动任务状态不断朝完成推进；关键：上下文工程决定决策质量，"看见什么"比"模型多大"更重要；工程化：靠 Harness 支撑框架做校验、容错、验证，遵循简单、透明、工具优先原则；选型：工作流与自主智能体无高下之分，按路径是否可预知选择，优先最小架构；安全：贯穿输入

在构建复杂的AI Agent系统时，我们常常面临一个架构抉择：是打造一个"全能"的单体Agent，通过集成多种工具调用（Tool Calling）来处理一切任务，还是将其拆分为多个职责单一的"子Agent"，通过协同合作来完成目标？这个问题不仅是面试中的"灵魂拷问"，更是决定系统能否在生产环境中稳定、高效、可扩展的关键。本文将深入剖析单体Agent与多Agent架构的本质区别，探讨何时必须"拆分"

AI Agent（智能体）通常被描述为“感知—规划—行动”的循环：接收用户输入或环境事件，调用大模型推理，再借助工具（检索、数据库、HTTP 接口、代码执行等）完成任务。一个看似简单的对话请求，背后可能串联多次 LLM 调用、知识库查询、工具调用和结果汇总，端到端耗时从几百毫秒到几十分钟不等。，让各环节按自身节奏消费、重试和扩展。Kafka 是可选方案之一，而非天然唯一解；下文会专门讨论它的适用前