当我们谈论 AI Agent 时，几乎所有现有方案都将其设计为 “协作者”：人类发出指令，Agent 响应；或者 Agent 调用工具后向人类汇报结果。这种范式源于 ChatGPT 带来的对话交互范式，但将 Agent 限制在了 “副驾驶” 的角色 —— 它需要解释自己在做什么，需要用人类可理解的语言沟通，需要等待人类的确认。这种设计带来了高昂的认知负载：人类必须持续关注 Agent 的输出、理解其思考过程、纠正其误解。
著名计算机科学家 Mark Weiser 在《The Computer for the 21st Century》一文中曾指出，最深刻的技术是那些 “消失” 的技术 —— 它们融入日常生活的纹理之中，直到与生活不可分离。这一洞见不仅适用于人机交互，同样适用于 Agent 与软件系统的关系。当我们将 Agent 视为必须与之 “对话” 的外部实体时，我们实际上在创造另一种需要人类持续照料的系统。反之，如果我们能将 Agent 嵌入现有软件架构，成为运行环境的一部分而非外部调用者，Agent 就能以更低噪声、更高效率的方式运作 —— 这才是面向机器的 “安静技术”。
嵌入式 Agent 的核心设计模式
将 Agent 嵌入现有软件并非简单地将 LLM 调用封装进一个函数。嵌入式 Agent 需要软件基础设施提供特定的接口支持，这些模式已经在部分系统中得到实践验证。
首先是声明式配置接口。传统软件暴露的是命令式 API—— 告诉系统 “怎么做”；而嵌入式 Agent 需要的是声明式接口 —— 告诉系统 “要什么”。当 Agent 可以用 SQL、配置文件或清单描述期望状态时，它就不再需要理解系统的内部实现细节，也不需要将复杂的状态同步信息转译为人类可读的报告。系统接收的是精确的语义描述，输出的是结构化的变更结果。
其次是 Reconcile 循环。Kubernetes 将声明式状态与持续收敛的概念普及开来，这一模式同样适用于嵌入式 Agent。Agent 声明目标状态，系统持续检测当前状态与目标状态的偏差并自动修正。Agent 不再需要轮询系统询问 “当前状态如何”，而是订阅偏差通知，在系统完成收敛后收到回调。这种模式将交互从 “请求 - 响应” 转变为 “声明 - 观察”，大幅降低了通信开销和认知负载。
第三是变化数据捕获（CDC）机制。这是最容易被忽视但对 Agent 效率影响最大的模式。大多数系统向 Agent 暴露的是静态快照 —— 表格、仪表盘、CSV 导出。Agent 需要定期查询、比对、猜测哪些数据发生了变化。这种轮询模式不仅计算成本高昂，而且 Agent 始终在处理 “过时的” 信息。真正的解决方案是让数据库主动推送变化事件：插入、更新、删除，每条记录的变化都精确对应到具体的事务。Agent 不再问 “什么改变了”，而是直接接收 “这改变了”。
Feldera 的增量计算范式与嵌入式 Agent
Feldera 作为增量计算引擎，其架构设计天然契合嵌入式 Agent 的需求。Feldera 不是传统的关系型数据库或流处理系统，而是一种能够对任意 SQL 程序进行全量增量计算的引擎。当数据发生变化时，Feldera 不会重新计算整个结果集，而是仅处理受影响的部分，将变化传播到所有依赖的视图。
这种增量计算模型映射到嵌入式 Agent 场景，带来几个关键优势。其一，毫秒级响应能力。在一台普通笔记本电脑上，Feldera 即可达到每秒数百万事件的处理速度，这意味着 Agent 可以在数据变化发生的瞬间获得计算结果，无需等待批量处理周期。其二，统一离线与在线计算。Agent 可以同时访问实时流数据和历史批数据，无需维护两套查询逻辑或在不同系统间切换。其三，精确的变化推送。与传统的轮询模式不同，Feldera 的视图输出本身就是一系列变化事件 —— 插入、更新、删除，每条输出都精确描述了对结果集的影响。Agent 订阅的是变化流，而非静态快照。
以欺诈检测场景为例。在传统架构中，Agent 需要定期扫描大量交易表，根据规则筛选可疑交易。这种轮询不仅延迟高，而且每次都需要重新评估全量逻辑。在基于 Feldera 的嵌入式架构中，Agent 定义一个 SQL 视图描述欺诈规则，然后将视图注册到增量引擎。当新交易插入时，Feldera 仅针对该交易计算视图表达式，输出精确的变化事件。Agent 订阅该变化流，在可疑交易出现时立即触发响应 —— 标记交易、请求人工复核、或自动阻断。整个过程无需 Agent 发起任何查询，系统在后台持续收敛，Agent 仅需处理变化通知。
工程落地的关键参数
将上述架构理念落实到工程实践，需要关注几个关键配置参数。首先是 Pipeline 的生命周期管理。Feldera Pipeline 支持启动、暂停、恢复三种状态。嵌入式 Agent 场景中，建议将 Pipeline 初始置于暂停状态，由 Agent 完成初始化数据导入和视图定义后启动。暂停操作可用于 Agent 需要批量修改输入数据而不想触发中间计算的场景。
其次是 Connector 配置。Feldera 提供了丰富的输入输出连接器，包括 Kafka、HTTP、CDC 流、S3 等。对于嵌入式 Agent，推荐使用 CDC 兼容的输入连接器（如 Debezium 适配器），确保输入表接收的是增量变更而非全量快照。输出连接器可配置为 HTTP Webhook 或 Kafka Topic，将变化事件推送到 Agent 的订阅端点。
第三是状态管理策略。Feldera 支持将状态和物化视图持久化存储，与输入数据协同设计以优化访问模式。对于需要 Agent 长时间运行的场景，建议启用故障恢复功能，确保在异常终止后能从精确的检查点恢复，避免数据丢失或重复处理。
最后是查询模式的选取。虽然 Feldera 支持在运行中的 Pipeline 上执行即席查询（使用 Apache DataFusion 进行批量评估），但嵌入式 Agent 应优先使用增量视图订阅而非即席查询。即席查询适用于调试场景，生产环境中 Agent 应依赖增量变化流以获得最佳性能。
从协作者到组件的范式转变
将 AI Agent 从 “协作者” 重新定位为 “嵌入式组件”，不仅是架构选择的变化，更是人机交互哲学的转变。当 Agent 不再需要用自然语言解释自己在做什么，不再需要等待人类的确认和批准，它就不再是系统中一个需要额外认知资源照顾的实体，而是融入软件运行时的后台进程。这种转变带来的效率提升是根本性的：Agent 可以同时监控多个数据源、响应多个事件、执行多个收敛任务，而不会产生人类需要处理的 “沟通噪声”。
Feldera 的实践表明，数据库系统可以在这一转变中扮演关键角色。增量计算引擎不仅是性能优化工具，更是实现 “机器间安静协作” 的基础设施。当数据库主动推送变化而非被动响应查询，当计算逻辑持续收敛而非周期重算，Agent 就能真正成为软件架构的内置组件，而非需要额外对接的外部系统。这一范式正在重新定义我们构建智能软件的方式。