个人简介
作者简介:全栈研发,具备端到端系统落地能力,专注大模型的压缩部署、多模态理解与 Agent 架构设计。 热爱“结构”与“秩序”,相信复杂系统背后总有简洁可控的可能。
我叫观熵。不是在控熵,就是在观测熵的流动
个人主页:观熵
个人邮箱:[email protected]
座右铭:愿科技之光,不止照亮智能,也照亮人心!
观熵系列专栏导航:
AI前沿探索:从大模型进化、多模态交互、AIGC内容生成,到AI在行业中的落地应用,我们将深入剖析最前沿的AI技术,分享实用的开发经验,并探讨AI未来的发展趋势
AI开源框架实战:面向 AI 工程师的大模型框架实战指南,覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉:聚焦计算机视觉前沿技术,涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战:持续更新的国产开源大模型部署实战教程,覆盖从 模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理 的完整全流程
TensorFlow 全栈实战:从建模到部署:覆盖模型构建、训练优化、跨平台部署与工程交付,帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏: PyTorch 框架的全栈实战应用,涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT:深入解析 TensorRT 的核心机制与部署实践,助力构建高性能 AI 推理系统
Megatron-LM 实战笔记:聚焦于 Megatron-LM 框架的实战应用,涵盖从预训练、微调到部署的全流程
AI Agent:系统学习并亲手构建一个完整的 AI Agent 系统,从基础理论、算法实战、框架应用,到私有部署、多端集成
DeepSeek 实战与解析:聚焦 DeepSeek 系列模型原理解析与实战应用,涵盖部署、推理、微调与多场景集成,助你高效上手国产大模型
端侧大模型:聚焦大模型在移动设备上的部署与优化,探索端侧智能的实现路径
行业大模型 · 数据全流程指南:大模型预训练数据的设计、采集、清洗与合规治理,聚焦行业场景,从需求定义到数据闭环,帮助您构建专属的智能数据基座
机器人研发全栈进阶指南:从ROS到AI智能控制:机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全:通过实战案例和系统化方法,帮助开发者和安全工程师识别风险、构建防御机制,确保 AI 系统的稳定与安全
智能 DevOps 工厂:AI 驱动的持续交付实践:构建以 AI 为核心的智能 DevOps 平台,涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记?:聚焦于现代 C++ 编程的核心概念与实践,涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战:从数据、策略到实盘,打造全栈智能量化交易系统
大模型运营专家的Prompt修炼之路:本专栏聚焦开发 / 测试人员的实际转型路径,基于 OpenAI、DeepSeek、抖音等真实资料,拆解 从入门到专业落地的关键主题,涵盖 Prompt 编写范式、结构输出控制、模型行为评估、系统接入与 DevOps 管理。每一篇都不讲概念空话,只做实战经验沉淀,让你一步步成为真正的模型运营专家。
Foundation Agent 的核心价值,不仅在于它能完成任务,更在于它具备可组合、可升级、可演化的能力结构。
这意味着:一个 Agent 不该是一个 prompt + LLM 的黑盒,而应是由多个**能力模块(Modules)**组成的系统智能体。
本篇我们将拆解 Foundation Agent 架构中最具通用性的结构原则:“模块化 Agent 架构设计”。包括能力粒度的拆分范式、模块接口标准化方式、能力动态组合调度策略,以及在多 Agent 环境下的协同执行与能力复用体系。
这是一篇从“能力构造”角度思考 Agent 架构的关键内容。真正把 Agent 当“系统工程”做的同学,必须掌握的能力体系搭建篇。
很多人在构建 Agent 时,第一步是这样的:
“我写一个 prompt + 接个模型 + 做个工具调用链 → 成了!”
确实,这能“跑”,也能“产出”,但你会很快发现它的问题:
问题的本质不是“模型不行”,而是:
你没把 Agent 当一个“由多个能力模块组成的结构体”来设计。
模型提供认知基础,但能力由模块定义,行为由调度系统激活。
换句话说,大模型是大脑皮层,Agent 模块才是肌肉神经元。
原因 | 说明 |
---|---|
能力可组合 | 一个写作能力模块,可用于日报 / 总结 / 报告多个任务 |
能力可升级 | 模块 A 可被替换为新模型、脚本、外部系统 |
能力可观测 | 每个模块输入输出明确,行为可追踪、可调试 |
系统可扩展 | 新能力模块注册即可,不影响已有系统运行 |
Agent 可调度 | Planner 可基于能力图谱自由组合新任务执行路径 |
把大模型“不可控的泛智能”,转化为系统“可控的组合智能”。
从最小能力单元 SkillUnit 到模块系统 AgentModule
你知道要模块化,那下一个问题就是:
“能力到底该怎么拆?”
拆得太细,系统维护成本高、Planner 不知所措;
拆得太粗,复用性差、组合灵活度低。
层级 | 名称 | 粒度 | 举例 |
---|---|---|---|
L1 | SkillUnit(技能单元) | 最小动作,功能单一 | 提取日期、判断是否否定句 |
L2 | AgentModule(模块) | 可独立调用的功能集 | 数据解析模块、摘要生成模块 |
L3 | CapabilityGroup(能力组) | 面向场景组合能力 | 日报生成能力、对话管理能力 |
def is_negative_sentence(text: str) -> bool:
# SkillUnit
class SummaryModule:
def receive(self, text):
return generate_summary(text)
{
"name": "日报生成",
"modules": [
"OCRParser", "KeyFigureExtractor", "SummaryModule", "TemplateFiller"
]
}
拆分原则 | 含义 |
---|---|
单一功能原则 | 一个模块/单元只做一件事 |
可独立调用 | SkillUnit/Module 可独立运行、独立测试 |
可组合性优先 | 拆的目的是组合出更多能力,不是追求最小 |
如果你想让 Agent 模块能像乐高积木一样拼接、组合、动态调度,你必须统一模块之间的通信协议。
不是靠 prompt 拼,而是靠结构化接口。
每个模块应该实现统一的 receive 接口,输入明确、输出可校验、状态可感知。
推荐模块标准化抽象接口:
class AgentModule:
def __init__(self, name):
self.name = name
def receive(self, input_struct: dict, context: dict = None) -> dict:
raise NotImplementedError
推荐参考 OpenAI Function / Tool Calling 协议,采用结构化 schema:
{
"input": {
"text": "请帮我生成一个日报",
"user_preferences": {
"style": "深色模版",
"language": "中文"
}
},
"context": {
"task_id": "t-001",
"agent_role": "Planner",
"memory": {...}
}
}
模块输出应符合如下结构:
{
"output": {
"summary": "今日销售额123万,同比增长12%",
"recommendation": "加强渠道推广"
},
"status": "success",
"duration_ms": 1273
}
原因 | 效果 |
---|---|
可组合 | Planner 可自动识别输入/输出进行连接 |
可复用 | 同一个模块可用于多个 Agent,甚至多个系统 |
可观测 | 每个模块行为可 Trace,可回放,可训练 |
可插拔 | 模块换成别的 LLM / Tool 实现不影响调用者 |
可调度 | 系统可根据输入结构自动匹配能力模块池 |
每个模块调用时,需支持上下文 context 字段传递:
{
"memory": { "user_name": "小李", "习惯模板": "日报-V2" },
"task_id": "t-289",
"agent_stack": ["Planner", "Executor"]
}
可用于:Memory 读取、Trace 记录、行为 Patch 设计等
多模块能力如何“临时组队协作”?
模块化系统的真正价值,不是你写了 20 个模块,而是:
系统能“临时组队”,组合这些模块完成任务,不需要你手动排布路径。
模式 | 特征 | 示例 |
---|---|---|
静态链式调用 | 模块顺序固定 | A → B → C |
Planner 编排 | 由智能体动态决定模块组合 | Planner 决定调用顺序 |
模块图谱执行(Module Graph) | 模块组合为图结构,节点间流转受控制器调度 | 具备依赖关系、条件跳转、循环等 |
Planner 负责规划模块执行顺序,Orchestrator 负责调度执行 + 状态传递
plan = planner.generate_plan(task_input)
for step in plan:
module = module_registry[step["module"]]
output = module.receive(step["input"], context)
context.update(output)
将模块连接关系建模为有向图:
{
"nodes": ["OCR", "KPIExtractor", "Summarizer", "Formatter"],
"edges": [
["OCR", "KPIExtractor"],
["KPIExtractor", "Summarizer"],
["Summarizer", "Formatter"]
]
}
这使得系统可以:
能力 | 机制 | 是否需要 |
---|---|---|
模块注册表 | 所有模块名称 → 实现对象映射 | ✅ 必须有 |
模块能力声明 | 每个模块的输入/输出 schema 描述 | ✅ 可用于 Planner 选择 |
Trace Hook | 每个模块调用都生成 Trace Step | ✅ 用于可观测性 |
状态快照管理 | 上下文在模块链中的传递与修改记录 | ✅ 用于 Debug / Replay |
如何为自己的 Agent 系统设计能力模块层?
大模型 Agent 不是 prompt 拼接工,而是一个系统调度结构,
而“模块系统”就是这个结构里最基础的**“动作单位”**。
本章我们将手把手带你完成以下三件事:
以“日报生成 Agent”为例。不要直接用大模型生成,而是拆成可复用模块:
子任务 | 推荐模块名 | 类型 | 可复用场景 |
---|---|---|---|
识别截图中的文字 | OCRModule |
工具封装 | 文档解析 / 票据识别 |
提取关键指标 | KPIExtractor |
Prompt LLM | 财报分析 / BI |
生成摘要 | SummaryModule |
LLM | 报告生成 / 教育总结 |
模版填充 | TemplateFiller |
模型或规则 | 智能文档系统 |
所有模块继承统一抽象:
class AgentModule:
def receive(self, input_struct: dict, context: dict = None) -> dict:
raise NotImplementedError
示例模块实现:
class KPIExtractor(AgentModule):
def receive(self, input_struct, context=None):
prompt = f"从以下文本中提取 KPI:{input_struct['text']}"
output = llm_call(prompt)
return {"kpi": output}
class ModuleRegistry:
def __init__(self):
self.modules = {}
def register(self, name, module: AgentModule):
self.modules[name] = module
def get(self, name):
return self.modules.get(name)
注册模块:
registry = ModuleRegistry()
registry.register("kpi_extractor", KPIExtractor())
registry.register("summary", SummaryModule())
模拟一个 Planner 返回模块组合计划:
plan = [
{"module": "ocr", "input": {"image": "path/to/screenshot"}},
{"module": "kpi_extractor", "input": {"text": "${ocr.text}"}},
{"module": "summary", "input": {"kpi": "${kpi_extractor.kpi}"}}
]
Orchestrator 执行:
def execute_plan(plan, registry):
context = {}
for step in plan:
module = registry.get(step["module"])
resolved_input = resolve_variables(step["input"], context)
output = module.receive(resolved_input, context)
context[step["module"]] = output
return context
resolve_variables()
函数可以用简单变量替换方式:
def resolve_variables(input_struct, context):
for k, v in input_struct.items():
if isinstance(v, str) and "${" in v:
ref = v.replace("${", "").replace("}", "")
mod, field = ref.split(".")
input_struct[k] = context[mod][field]
return input_struct
每次模块执行都记录一条 Trace:
trace = []
def execute_with_trace(plan, registry):
context = {}
for step in plan:
module = registry.get(step["module"])
input_data = resolve_variables(step["input"], context)
output = module.receive(input_data)
context[step["module"]] = output
trace.append({
"module": step["module"],
"input": input_data,
"output": output
})
return context, trace
{
"name": "kpi_extractor",
"input_schema": {
"type": "object",
"properties": {
"text": {"type": "string"}
},
"required": ["text"]
},
"output_schema": {
"type": "object",
"properties": {
"kpi": {"type": "string"}
}
}
}
至此,你拥有了一个:
✅ 可组合、可复用、可调度、可追踪的 Agent 模块系统底座
步骤 | 工程要点 |
---|---|
拆模块 | 从任务出发,拆成 SkillUnit × AgentModule × CapabilityGroup |
封装模块 | 用统一 AgentModule 接口,标准输入输出 |
注册模块 | ModuleRegistry + Schema 信息维护 |
调度模块 | Planner 返回 Plan,Orchestrator 实际执行 |
Trace 记录 | 每步输出结构化日志,可用于 Debug / Replay / 学习 |
可视化 | Trace → Timeline / Flow Diagram / Failure 分析图 |
Foundation Agent 想做到通用、可持续、可成长,靠的绝不是一个 prompt 写得多好、模型调得多准,而是:
能力是否可以标准化组合,行为是否可以被系统性调度。
维度 | 传统黑盒 Agent | 模块化 Foundation Agent |
---|---|---|
复用 | 每次写新 prompt | 能力模块可跨任务重用 |
扩展 | 新任务 = 全重写 | 注册新模块即支持新目标 |
控制 | 行为不可观测 | 每一步可 Trace、Replay、调优 |
反馈 | 不可 Patch | 每个模块都能被独立打分与替换 |
你已经掌握了:
这些不是为了“炫技”,而是为了一个目标:
构建可成长的智能系统,而不是一次性可用的 Agent。
模块能力评估机制构建
模块图谱自动生成机制
Agent 自我演化机制设计
模块 + Tool 双核运行结构设计
如果你能把“模块系统 + 调度系统 + 行为反馈 + 多 Agent 协作”真正跑起来,你就不是在做 Agent,而是在做:
一个小型的 AI 操作系统。
点个赞,给我一些反馈动力
⭐ 收藏起来,方便之后复习查阅
关注我,后续还有更多实战内容持续更新
写系统,也写秩序;写代码,也写世界。
观熵出品,皆为实战沉淀。