文章介绍了ACE(Agentic上下文工程)框架的原型实现，该框架通过上下文自我演化而非模型微调实现智能体"自学成长"。系统包含四个核心组件：Playbook(策略手册)存储学习策略；Generator(行动者)执行任务并生成推理轨迹；Reflector(复盘者)分析执行过程并提炼经验；Curator(策略管家)将反思转化为策略更新。文章详细展示了各模块实现逻辑、工作流组装与测试，并讨论了当前局限与改进方向，为构建可自主学习进化的智能体系统提供了实践参考。

在上篇中，我们了解到ACE(Agentic上下文工程)框架的核心理念：不依赖模型微调，而是通过上下文的自我演化，让智能体实现“自学成长”。

本篇参考 ACE 论文中的架构与提示词设计，实现一个可自我学习与进化的 ACE 智能体原型，帮助你更直观地理解 ACE 在实际系统中的运作机制。

内容概览：

  • 整体架构与流程
  • 实现Playbook – “策略手册”
  • 实现Generator – “行动者”
  • 实现Reflector – “复盘者”
  • 实现Curator – “策略管家”
  • 工作流组装与测试
  • 问题与改进方向

本文参考源代码在文末。

整体架构与流程

参考 ACE 论文提出的结构，我们将其应用于一个基于 ReAct 范式 的智能体中。这个智能体具备自我“反思—学习—成长”的能力：

【设计要点】

  1. 用ReAct Agent代表Generator（行动者）
  • 用一个ReAct Agent来承担Generator校色，接受输入任务，输出答案与推理过程。当然，实际应用中可以是任何形态的Agent。
  1. 离线模式与在线模式

关于ACE论文中的两种典型运行模式：

  • 离线模式（Offline Adapter）

    即"训练模式"，用来在固定的训练数据集上多轮迭代运行ACE流程，每轮处理相同的样本，生成初始的策略库（Playbook）。这类似于学生反复做题，总结规律，积累经验。

  • 在线模式（Online Adapter）

    即"生产模式"：部署到真实业务场景中。此时输入数据不再固定，也不会多次迭代，但智能体会根据新任务实时更新 Playbook。它更像是一个在实战中不断成长的从业者，边工作边学习。

两者间的“协作”大概是这样：

两者间的区别用下表总结：

实际上，对于单次任务输入（迭代次数=1） 的情况，两者在基本流程上并无本质区别。因此我们可以构建一个统一的工作流结构：

  • 若需“预训练”，只需在固定数据集上重复运行多轮
  • 若直接“生产”，则让工作流持续接收新输入并在线更新策略

接下来，我们将逐步拆解各个模块的实现逻辑，从 Playbook 开始（为了更好地聚焦于 ACE 框架的核心逻辑，原型实现做了很多简化）。

实现Playbook – “策略手册”

Playbook 是 ACE 系统的"记忆中枢"，负责存储和管理 Agent 在实践中学到的所有策略。不仅记录Agent在不同任务中的“经验与教训”，还通过评分机制和语义检索，让Agent在后续任务中能够主动调用最优策略。

结构如下：

【设计要点】

  1. 多样的检索策略

Playbook 提供两种检索方式：

  • 基于评分：基于评分优先返回表现好的策略
  • 基于语义：借助向量实现语义级检索

2. 动态学习与优胜劣汰

每条策略都会在任务执行后根据反馈被打上标签（helpful / harmful / neutral）。系统根据这些反馈自动计算得分（Score）：

score = helpful_count - harmful_count

高分策略在检索时权重更高，而低分策略会逐步被淘汰。这使得智能体的经验体系具备自我优化能力。

3. 策略去重与整合

为避免知识冗余，Playbook 会在新增策略时进行去重检测（基于向量相似度）。当系统检测到已有相似策略时，不会简单新增，而是更新已有策略的统计信息。

  1. 持久化与可重建

支持将Playbook持久化（文件或数据库），在系统重启后可快速加载使用，同时在模型或存储结构变化后，也能快速重建语义索引。

【策略结构】

每个策略包含有内容、分类标签、使用反馈与实践信息等。

class Strategy:
id: str # 唯一标识
    content: str # 策略内容
    category: str # 分类（如 "react", "calculation"）
    helpful_count: int# 有效次数
    harmful_count: int# 有害次数
    neutral_count: int# 中性次数
    created_at: str # 创建时间
    updated_at: str # 更新时间

   @property
    def score(self):
# 净得分 = 有效次数 - 有害次数
returnself.helpful_count - self.harmful_count
...

【策略样例】

以下是一条典型的策略示例：

"dat-00007": {
"id": "dat-00007",
"content": "信息来源评估原则：在确认信息时，必须对每个信息来源进行权威性评估。步骤：1) 获取多个来源的信息；2) 评估来源的权威性，例如是否为政府机构或知名组织；3) 选择最权威的来源并说明选择理由；4) 若存在差异，需给出合理解释。",
"category": "data_verification",
"helpful_count": 1,
"harmful_count": 0,
"neutral_count": 0,
"created_at": "2025-10-31T04:24:00.338080+00:00",
"updated_at": "2025-10-31T04:24:00.338084+00:00"
    }

通过这样的结构，Playbook 在执行阶段能动态调用最优策略，在反思阶段生成并吸收新策略，最终形成一个能够持续自我进化的“知识系统”— 让Agent不仅记得“做过什么”，还知道“怎样可以做得更好”。

实现Generator – “行动者”

Generator 是 ACE 框架中的执行者。它可以是一次简单的 LLM 调用。我们采用****ReAct范式的 Agent：根据输入问题生成可验证的答案，并产生可追溯的“推理轨迹”，供后续 Reflector 与 Curator 使用：

【设计要点】

  1. 用ReAct驱动任务执行

借助LangChain的create_agent创建，让模型在需要时自动调用工具（通常是通过 Function Calling功能）。

这种基于FunctionCalling的Agent在输出“推理轨迹”时不太友好。详见最后一节“问题”部分。

  1. 工具集成

配备简单的计算器与搜索引擎用于测试。

  1. 策略注入
  • 每次任务开始前，从 Playbook 检索问题相关的Top-K策略（基于分数或语义，注意不是所有策略都适合语义检索）。
  • 将这些策略以“片段/指南”的形式动态注入系统提示，作为经验性先验，引导 ReAct 的思考与工具选择。
def_get_or_create_agent(self, question: str = "", context: str = ""):
"""
        根据当前问题动态创建 agent，以便使用最相关的策略。

        参数：
            question: 当前问题
            context: 额外的上下文信息
        """
return create_agent(
            model=f"openai:{self.model_name}",
            tools=self.tools,
 system_prompt=self._get_system_prompt(question, context)
        )
  1. 动态系统提示（上下文）

系统提示词动态组装，包含内容有：

  • Top-K 相关策略（含策略 ID，便于追溯）
  • 工作原则与关键指令（如：必须逐步输出、遇到不确定先验证等）
  • 工具使用说明（可选，FunctionCalling不需要）
  • 任务上下文与边界（输入背景、约束、期望输出格式）
  1. 结构化与可审计输出

为了方便后续Reflector的“复盘”，要求ReAct在每轮：

  • 输出简明的“思考”过程（Reasoning）
  • 明确所引用的Playbook策略ID
  • 清晰标准工具调用相关信息

执行结束整理为统一的数据结构，至少包括：

  • 最终答案（Final Answer）
  • 推理轨迹（每轮Reasoning/Action序列）
  • 使用的策略ID列表（用于之后的策略评估与计分）

总之，Agent的“思考”过程越详细，越有利于后续Reflector的“复盘”；这和做数学题一样：过程越详细，越有利于“复查”发现问题。

实现Reflector – “复盘者”

它对 Generator（行动者）的推理链与执行轨迹进行系统化复盘，围绕三个关键问题给出结构化结论：

「哪里做得好？哪里出了错？下一次该怎么做得更好？」

【设计要点】

  1. 适应有无ground_truth两种模式
  • 有ground_truth：先用评估器对最终答案与标准答案进行比对，生成客观评估信号（正确/错误、评估反馈、置信度）。Reflector 将该评估作为附加证据纳入分析，给出更精确的复盘结论。
  • 无ground_truth：采用自我审查策略，基于推理链一致性检查、工具调用合理性、来源可靠性等信号，评估结果可信度并提出改进建议。

类比：一种是“做作业时有参考答案的反思”；另外一种则是考试时无答案的复查。

  1. 多维度诊断（通过Prompt)

Reflector 从多个维度分析Agent的表现，而不是只判断对错。：

  • 成功模式：哪些策略、方法和推理链起到了正面作用？能否泛化？
  • 策略问题模式：哪些策略选择不当、理解偏差或逻辑跳跃？
  • 工具使用错误：是否调用了错误工具、参数是否合理？
  • 数据源问题：检索来源是否权威？信息是否一致？
  • 计算错误：检测到LLM不擅长的数值推理等。

通过这种方式产出根因分析、改进建议、关键洞察等高价值输出。

  1. 策略使用评估

Reflector不仅要发现新的可用策略，更要对旧的策略使用进行评估：

  • helpful：明确帮助了任务推进或提高了答案质量；

  • harmful：误导了推理或导致错误；

  • neutral：影响不大或无关。

    并给出简短理由，作为 Curator 更新 Playbook 计数与内容的依据。

【输出结构（建议）】

from dataclasses import dataclass
from typing import List

@dataclass
class StrategyTag:
    id: str # 策略ID
    tag: str # "helpful" | "harmful" | "neutral"
    justification: str # 标记理由（引用具体证据点）

@dataclass
classReflectionResult:
    reasoning: str # 系统化分析（精炼、可读）
    error_identification: str # 错误识别（发生了什么问题）
    error_location: str # 错误位置（哪一步/哪条消息/哪次工具调用）
    root_cause_analysis: str # 根因分析（为什么会错）
    correct_approach: str # 正确方法（可操作的改进建议）
    key_insight: str # 关键见解（可沉淀为策略的抽象经验）
    confidence_in_analysis: float # 置信度（0~1）
    strategy_tags: List[StrategyTag] # 对已用策略的评估标签

总之，Reflector 的价值在于从任务过程中提炼可执行的改进与可复用的经验。

实现Curator – “策略管家”

Curator 是 ACE 框架的“知识管理者”，它负责把 Reflector 的复盘结果转译为对 Playbook 的具体操作，让“经验教训”沉淀为可复用的策略，确保策略库持续进化且质量可控。

Curator有点像Text2SQL：把反思的结果转化成对Playbook的“SQL”操作

【设计要点】

  1. 策略操作类型

支持Playbook的多种操作类型，用于不同的策略更新场景：

* ADD：新增具体可执行且可泛化的策略（附简短示例/适用边界）

* UPDATE：对既有策略做增量补充（边界、例外、参数约束、误用警示）

* REMOVE：移除持续有害/过时/与事实冲突的策略

* 有效性计数更新：根据Reflector的输出，更新策略的有效性计数

  1. 质量控制

在Curator执行的过程加入质量控制是有必要的。其中最重要的是排重与合并（否则可能导致无限制的上下文增长），除了前面Playbook本身具备的基于向量的重复检查外，可以在Curator的提示中加入对现有策略的相似度判断（比如相似度较高，则使用UPDATE而不是ADD）。

输出结构（建议）

from dataclasses import dataclass
from typing import List, Dict, Any

@dataclass
class CurateOperation:
    operation: str # "ADD" | "UPDATE" | "REMOVE" | "MARK"
    strategy_id: str = ""# 适用于 UPDATE / REMOVE / MARK
    content: str = ""# 适用于 ADD / UPDATE（增量内容或补充要点）
    category: str = ""# 新增/调整的分类
    reason: str = ""# 操作原因（关联反思的证据/根因）
    priority: int = 3# 1~5，数值越小优先级越高
    tags: Dict[str, Any] = None# 可选：delta/edge_cases/examples 等

@dataclass
class CurateResult:
    operations: List[CurateOperation]
    added_count: int
    updated_count: int
    removed_count: int
    marked_count: int

总之，Curator 的职责不是“把反思照抄进库”，而是把反思变成策略学到库里。

工作流组装与测试

各模块就位后，我们用 LangGraph 把它们串成一个最小可用的工作流。目标很简单：把已有的 ReAct Agent“包一层”，让它具备执行 → 评估（可选）→ 反思 → 策展的闭环能力（你完全可以自行用代码实现这个流程）。

【工作流编排】

大致的编排直接看编排代码更清晰：

def_build_graph(self) -> StateGraph:
"""
        构建 LangGraph 工作流
        """
        workflow = StateGraph(ACEReActState)

# 添加所有节点
        workflow.add_node("react_agent", self._react_agent_node)
        workflow.add_node("evaluator", self._evaluator_node)
        workflow.add_node("reflector", self._reflector_node)
        workflow.add_node("curator", self._curator_node)

# 设置入口
        workflow.set_entry_point("react_agent")

# 使用条件边：react_agent 后根据是否有 ground_truth 决定路由
        workflow.add_conditional_edges(
"react_agent",
lambda state: "evaluator"if state["react_question"].ground_truth else"reflector",
            {"evaluator": "evaluator", "reflector": "reflector"}
        )

# evaluator 后续路径
        workflow.add_edge("evaluator", "reflector")

# reflector 和 curator 的路径
        workflow.add_edge("reflector", "curator")
        workflow.add_edge("curator", END)

return workflow.compile()

使用LangGraph的好处是把已有的ReAct Agent再编排成一个“具有自主学习能力”的Workflow；并获得流式输出、checkpoint、异步等特性。

【测试流程】

我们用一个简洁的主程序跑通闭环：先离线“预热”出初始 Playbook，再在线测试与继续学习。为方便演示，epoch=1。

【观察与产出】

首先是几个固定数据集的训练过程：

# 训练问题
questions = [
        ReactQuestion(
            question="计算 (25 + 17) * 3 - 8 的结果，并验证答案是否为偶数",
            ground_truth="118，是偶数",
            context=""
        ),
        ReactQuestion(
            question="搜索 Python 语言的创建者，并说明他创建 Python 的年份",
            ground_truth="Guido van Rossum，1991年",
            context=""
        ),
        ReactQuestion(
            question="搜索世界上最高的山峰名称和海拔高度，然后计算如果一个人每天爬升500米，需要多少天才能到达顶峰",
            ground_truth="珠穆朗玛峰，8849米，需要约18天",
            context=""
        )
]

我们在流程的每一步观察输出结果。

  • Generator输出

可以看到除了最终答案外，需要看到逐步 Reasoning / 工具调用 / 观察的完整轨迹。

  • Reflector输出

基于Generator的输出，结合答案的评估结果（Evaluator），进行诊断与反思，并将此轮的“经验教训”输出。

  • Curator输出

Curator根据Reflector的反思结果对Playbook增量更新，并输出本次迭代的“成果”统计（包括操作明细与摘要）。

  • 第一轮训练完成后的成果

在第一轮训练完成后可以得到一个可用的初始Playbook：

这个Playbook会用在后续的样本上：复用现有策略或者精炼已有策略。

比如你可能会在下一轮训练中看到对之前“策略”的引用：

也可能在下一轮训练中看到对现有策略的完善：

这正是ACE的意义：不是“每次从零做题”，而是“做一次、学一点，下次更好”。

  • 排重

在Playbook增量更新中，我们也观察到重复策略的排除：

  • 无监督场景测试

现在，初始的Playbook可以用于新的无监督（无ground_truth）测试样本：

而测试样本在执行过程中，也可能产生新的策略并更新Playbook。

问题与改进方向

现在总结下我们是如何把 Agent 放进一个会“学习”的流程里：

  • LangGraph 负责编排
  • ReAct 负责生成与输出推理轨迹
  • Reflector 负责把执行过程转化成“经验”
  • Curator 负责把“经验”变成资产（Playbook）

周而复始，你会发现：同一个 Agent，做第二次同类任务，已经更“聪明”了。

【问题与限制】

尽管 ACE 的原型验证取得了一定效果，但目前仍存在若干关键问题：

1. LLM 表现波动大

  • Generator 与 Reflector 都严重依赖LLM与提示设计
  • 即便相同的模型与提示，不同样本上的输出也可能不一致。特别是在基于 Function Calling 的 ReAct Agent 中，模型会在输出tool_calls后抑制本轮文本输出（content字段），导致“思考过程”或“策略引用”信息缺失

2. 策略增量更新的判定困难

Curator 在执行增量更新时，LLM 对“新增”与“更新”的边界判断并不稳定。常见问题包括：

  • 倾向于新增相似策略，而非更新原策略
  • 无法可靠检测重复或冲突策略
  • 更新内容缺乏上下文一致性

需要引入向量检索 + 相似度阈值（如 0.7）的排重逻辑辅助。

3. 同步反思导致性能瓶颈

Reflector/Curator的同步执行会显著拖慢主流程。在生产场景中，这种“实时复盘”模式并不现实，可以采取异步或延迟执行机制。

【改进方向思考】

1. 异步反思与批量学习

让 Reflector/Curator 异步运行，定期汇总反思结果并统一更新 Playbook，从而提升在线响应速度，同时保持学习闭环。

2. 领域化与定制化调优

ACE 不是一个“固定模板”，而是一种可演化的工程思想。在不同场景中，它的重心也会不同。比如，不同类型的智能体需要不同的反思与策略重点：

  • 工具型智能体：更关注工具调用逻辑、参数安全、错误恢复
  • 知识型智能体： 更注重专业知识积累、对话一致性与合规性

因此，实际落地时需根据业务场景、模型能力与目标指标进行调优。

3. Playbook 的生命周期管理

未来的策略库应支持：

  • 更完善的质量评分与退化淘汰机制
  • 版本管理与回滚（方便做 A/B 测试）
  • 并发一致性控制（多任务下策略更新冲突）
  • 检索优化（如何更好的选择最相关的策略）

5. 扩展性与组件化设计

  • 可扩展/插拔的 Evaluator/Reflector 等模块
  • 可替换的 Prompt 模板与策略过滤器
  • 面向不同领域的 Playbook 预设（如财务、科研、客服等）

ACE提出了一种创新思想，它不再依赖模型的训练，而是让Agent自我”训练“，通过不断迭代更新的上下文实现自我提升。这篇原型实现只是一个起点，我们还是期待在更多真正的生产应用里看到其实际的运行效果。

本文源码：

https://github.com/pingcy/ace-langgraph

普通人如何抓住AI大模型的风口？

为什么要学习大模型？

在DeepSeek大模型热潮带动下，“人工智能+”赋能各产业升级提速。随着人工智能技术加速渗透产业，AI人才争夺战正进入白热化阶段。如今近**60%的高科技企业已将AI人才纳入核心招聘目标，**其创新驱动发展的特性决定了对AI人才的刚性需求，远超金融（40.1%）和专业服务业（26.7%）。餐饮/酒店/旅游业核心岗位以人工服务为主，多数企业更倾向于维持现有服务模式，对AI人才吸纳能力相对有限。

在这里插入图片描述

这些数字背后，是产业对AI能力的迫切渴求：互联网企业用大模型优化推荐算法，制造业靠AI提升生产效率，医疗行业借助大模型辅助诊断……而餐饮、酒店等以人工服务为核心的领域，因业务特性更依赖线下体验，对AI人才的吸纳能力相对有限。显然，AI技能已成为职场“加分项”乃至“必需品”，越早掌握，越能占据职业竞争的主动权

随着AI大模型技术的迅速发展，相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业：

img

人工智能大潮已来，不加入就可能被淘汰。如果你是技术人，尤其是互联网从业者，现在就开始学习AI大模型技术，真的是给你的人生一个重要建议！

如果你真的想学习大模型，请不要去网上找那些零零碎碎的教程，真的很难学懂！你可以根据我这个学习路线和系统资料，制定一套学习计划，只要你肯花时间沉下心去学习，它们一定能帮到你！

大模型全套学习资料领取

这里我整理了一份AI大模型入门到进阶全套学习包，包含学习路线+实战案例+视频+书籍PDF+面试题+DeepSeek部署包和技巧，需要的小伙伴文在下方免费领取哦，真诚无偿分享！！！

vx扫描下方二维码即可

在这里插入图片描述

部分资料展示

一、 AI大模型学习路线图

这份路线图以“阶段性目标+重点突破方向”为核心，从基础认知（AI大模型核心概念）到技能进阶（模型应用开发），再到实战落地（行业解决方案），每一步都标注了学习周期和核心资源，帮你清晰规划成长路径。

img

二、 全套AI大模型应用开发视频教程

从入门到进阶这里都有，跟着老师学习事半功倍。

在这里插入图片描述

三、 大模型学习书籍&文档

收录《从零做大模型》《动手做AI Agent》等经典著作，搭配阿里云、腾讯云官方技术白皮书，帮你夯实理论基础。

在这里插入图片描述

四、大模型大厂面试真题

整理了百度、阿里、字节等企业近三年的AI大模型岗位面试题，涵盖基础理论、技术实操、项目经验等维度，每道题都配有详细解析和答题思路，帮你针对性提升面试竞争力。

在这里插入图片描述

适用人群

在这里插入图片描述

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么？
  • 大模型是怎样获得「智能」的？
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例：向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范
  • …
第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示（Embeddings）
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署
  • …
第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2：手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建
  • …
第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身：基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例：如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案
  • …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

在这里插入图片描述

# 学习 # 知识图谱 # 人工智能 # 深度学习 # 机器学习
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

从单体到微服务：AI架构师详解大规模AI系统部署的架构演进路径与策略

想象一下，在一个繁华的大都市中，有一座超级庞大的建筑，它就像一个单体的巨兽，承担着城市里所有的办公、居住、娱乐等功能。这座建筑虽然功能强大，但一旦某个部分出现故障，可能会影响到整个建筑的正常运转，而且想要对其进行改造和升级也非常困难。这就如同传统的单体AI系统，一个庞大的程序包含了所有的功能，虽然能完成复杂的任务，但在灵活性、可维护性等方面存在诸多问题。随着科技的发展，城市开始出现了许多小型的、功

avatar 2048 AI社区
cover

【大模型应用篇】用 OpenClaw + 飞书打造 7x24 小时服务器运维机器人

avatar 2048 AI社区
cover

多模态大模型学习笔记（一）——机器学习入门：监督/无监督学习核心任务全解析

avatar 2048 AI社区