1. 项目概述：当AI开始思考如何“进化”自己

最近在GitHub上看到一个挺有意思的项目，叫 wangzhxg/agent-evolution-advisor 。光看名字，就透着一股“元”味儿——一个“智能体进化顾问”。这可不是在教你怎么训练一个更好的聊天机器人，而是在探讨一个更深层的问题： 如果让AI自己去思考如何优化和迭代另一个AI，会发生什么？

这让我想起了软件工程里的“自举”概念，或者生物学里的“进化”。我们人类作为开发者，一直在扮演“上帝”的角色，为AI模型设计架构、准备数据、调整超参数。但这个项目似乎在尝试构建一个“元智能体”，它的核心任务不是直接解决某个具体问题（比如写代码、画图），而是去 观察、分析、评估并指导另一个“工作智能体”的进化路径 。简单说，就是打造一个AI的“教练”或“架构师”。

这个想法非常吸引人。在当前的AI应用开发中，我们常常陷入一个循环：发现问题 -> 人工分析 -> 手动调整 -> 重新训练。这个过程不仅耗时耗力，而且高度依赖专家的直觉和经验。 agent-evolution-advisor 项目试图将“分析”和“建议”这两个环节自动化、智能化。它可能通过分析工作智能体的历史交互记录、性能指标、失败案例，结合一些进化算法或强化学习的思路，来生成具体的改进建议，比如：“你的工具调用逻辑在遇到嵌套查询时容易混乱，建议引入一个思维链验证模块”，或者“你在处理长文本摘要时信息丢失严重，考虑增加一个递归提炼的步骤”。

这个项目适合谁呢？我认为有三类人会对它特别感兴趣：一是 AI智能体框架的研究者和开发者 ，他们可以借此探索智能体自我优化的理论边界；二是 追求极致自动化运维的AI应用团队 ，他们希望自己部署的智能体能够“越用越聪明”，降低长期维护成本；三是 对AI元认知、AI安全感兴趣的朋友 ，因为研究AI如何优化AI，本身就是在触碰“智能”的本质，其中关于目标对齐、评估标准的设计，都充满了挑战和启示。

接下来，我将基于我对智能体架构和自动化机器学习（AutoML）的理解，深入拆解这个项目可能涉及的核心思路、技术实现以及那些“坑”，希望能为你打开一扇窗。

2. 核心架构与设计哲学拆解

要理解“进化顾问”是怎么工作的，我们得先把它拆开来看。这个系统本质上是一个 双层智能体架构 ：上层是“顾问”（Advisor），下层是一个或多个“工作智能体”（Worker Agent）。顾问并不直接参与下层的任务执行，而是作为一个高阶的、具备反思和规划能力的“观察者”与“指导者”。

2.1 系统核心组件与数据流

一个典型的进化顾问系统，其核心运转离不开几个关键组件和它们之间的数据流动。我们可以想象这样一个场景：一个用于客服的对话智能体（工作智能体）在服务用户，而进化顾问在后台静静地观察着这一切。

1. 观察与监控模块（The Observer） 这是顾问的“眼睛”和“耳朵”。它需要以非侵入式的方式，全面采集工作智能体的运行数据。这些数据远不止是简单的“任务成功/失败”二元标签。一个设计良好的观察模块会收集：

  • 交互轨迹（Interaction Traces） ：完整的对话历史、工具调用序列、中间推理步骤（如果工作智能体支持思维链）。这是分析行为模式的基础。
  • 性能指标（Performance Metrics） ：针对具体任务定义的评估指标。例如，对于代码生成智能体，可能是单元测试通过率、代码风格评分；对于摘要智能体，可能是ROUGE或BERT分数。
  • 资源消耗（Resource Consumption） ：每次推理的Token消耗、API调用延迟、计算成本。优化不仅要效果更好，还要更经济。
  • “困惑”信号（Confusion Signals） ：工作智能体自身暴露的不确定性，例如多次修改回答、频繁调用搜索引擎、生成了“我不确定”之类的表述。

这些数据会被结构化地存储在一个 经验池（Experience Pool） 中，按时间、任务类型、会话ID等维度进行索引，为后续分析提供原料。

2. 分析与诊断引擎（The Analyst） 这是顾问的“大脑”。它负责从海量的观察数据中提炼出有价值的见解。这里的技术选型非常关键，直接决定了顾问的“智慧”程度。

  • 规则引擎（基础版） ：可以设置一些简单的启发式规则。例如，“如果连续三次工具调用都返回错误，则标记该工具使用逻辑存在缺陷”；“如果回答长度超过1000字符且用户满意度下降，则可能存在冗余”。
  • 机器学习模型（进阶版） ：这是更强大的方式。可以将工作智能体的交互轨迹和最终性能指标作为输入，训练一个诊断模型。这个模型可以学习到复杂的模式，比如“在涉及多步数学推理的场景中，如果智能体跳过了验算步骤，其最终答案的错误率会显著上升”。
  • 大语言模型（LLM）驱动（当前主流） ：利用LLM强大的模式识别和自然语言理解能力，直接对交互轨迹进行“复盘分析”。你可以给LLM（如GPT-4、Claude 3）提供一段对话历史，并提问：“请分析其中的智能体在哪些环节出现了问题？可能的改进方向是什么？” LLM能够给出非常具有洞察力、类似人类专家的文本分析。

3. 建议生成与规划模块（The Strategist） 分析出问题后，需要转化为可执行的改进方案。这个模块负责生成具体的“进化建议”。建议可以多个层次：

  • 提示词（Prompt）优化 ：微调系统提示（System Prompt），增加约束条件、提供更好的Few-shot示例、优化角色设定。
  • 工作流（Workflow）重构 ：建议修改智能体的推理步骤。例如，从“直接回答”改为“先规划大纲，再检索知识，最后整合输出”。
  • 工具（Tools）增删改 ：建议开发新的工具函数、禁用效果不佳的工具，或调整工具调用的优先级。
  • 底层模型切换或微调建议 ：在成本允许的情况下，建议更换为更适合该任务的基础模型，或者指出哪些领域的数据可以用于进一步的微调（Fine-tuning）。

这个模块同样可以基于规则或LLM。LLM在这里可以发挥创造力，例如：“针对‘代码调试’场景，我建议引入一个‘ Rubber Duck Debugging ’工具，让智能体先将问题解释给一个虚拟的橡皮鸭，这常常能帮助它自己理清思路。”

4. 评估与实验管理模块（The Evaluator） 建议不能盲目实施。顾问需要有一套机制来评估建议的潜在价值。这通常通过 模拟实验（Simulation） 或 小范围A/B测试 来完成。

  • 系统可以创建一个工作智能体的“克隆体”，并对其应用生成的建议（如修改后的提示词）。
  • 然后，让这个克隆体在一批历史任务或新构建的测试用例上运行。
  • 比较克隆体与原版智能体的性能指标，量化改进效果（提升百分比）或回归风险。
  • 只有那些通过评估、达到预设改进阈值（例如，准确率提升>5%且成本增加<10%）的建议，才会被正式推荐给人类管理员审核或自动部署。

整个数据流形成一个闭环：观察 -> 分析 -> 建议 -> 评估 -> （实施后）再观察。这本质上构建了一个 基于数据的持续集成与持续部署（CI/CD）管道，但对象是AI智能体本身 。

2.2 关键设计抉择与权衡

在设计这样一个系统时，会面临几个核心抉择：

1. 在线学习 vs. 离线分析

  • 在线学习 ：顾问实时监控，发现问题即时给出建议甚至热更新。优点是响应快，能快速适应变化。缺点是风险高，可能引入不稳定因素，且对系统架构的实时性要求极高。
  • 离线分析 ：定期（如每天/每周）对积累的日志进行批量分析，生成周期性的进化报告。优点是安全、稳定、分析可以更深入全面。缺点是延迟高，无法应对突发性性能退化。

    实操心得 ：对于生产环境，强烈建议从 离线分析 开始。建立一个每晚运行的定时任务，分析过去24小时的数据，次日早上向开发团队发送一份“智能体健康与优化报告”。这既能提供价值，又完全可控。在线学习可以作为远期目标，在拥有极其可靠的评估和回滚机制后再考虑。

2. 通用顾问 vs. 领域专家顾问

  • 通用顾问 ：试图用一个模型来优化所有类型的工作智能体。优点是架构统一，节省资源。缺点是难以深入特定领域的细节，建议可能流于表面。
  • 领域专家顾问 ：为不同类型的智能体（客服、编程、分析）定制专用的分析逻辑和建议模板。优点是建议精准、可操作性强。缺点是开发和维护成本成倍增加。

    实操心得 ：采用 分层策略 。底层是一个通用的分析框架（负责数据收集、基础指标计算）。上层则针对不同领域，配置特定的“诊断插件”和“建议模板库”。例如，为代码智能体配置的插件会关注代码风格、安全漏洞；为客服智能体配置的插件则关注情绪识别、问题解决率。

3. 自动化程度：全自动、半自动还是辅助工具？ 这是最重要的哲学抉择，直接关系到系统的定位和安全性。

  • 全自动 ：顾问分析、生成建议、评估、自动部署到生产环境，完全无需人工干预。这是终极目标，但当前技术下风险极高，容易导致智能体行为失控或性能滑坡。
  • 半自动 ：顾问完成分析、生成建议和初步评估，然后将一份带有优先级排序和置信度评分的“优化方案清单”提交给人类开发者审批。人类拥有最终决策权。
  • 辅助工具 ：顾问仅作为一个强大的分析仪表盘，可视化地展示智能体的弱点、瓶颈和潜在改进点，所有的修改动作都由人类手动完成。

    实操心得 ：在项目初期，坚定地定位为 辅助工具 或 半自动（以人类审批为核心） 。将顾问的输出视为“高级别诊断报告”和“灵感来源”，而非“操作指令”。这能有效控制风险，并让人类专家始终保持对智能体进化方向的主导权。可以在一个独立的沙箱环境中尝试全自动闭环，用于研究目的。

3. 技术实现深度解析

聊完了设计理念，我们深入到技术实现的泥潭里看看。要实现一个可用的进化顾问，我们需要在工程上解决一系列具体问题。这里我以基于LLM驱动的分析引擎为例，拆解几个核心模块的实现细节。

3.1 观察模块：如何高效、无侵入地收集数据

数据是燃料，收集方式决定了燃料的质量。对于基于LLM的智能体（如使用LangChain、LlamaIndex、AutoGen等框架构建），数据收集通常有几种方式：

1. 框架层拦截（推荐） 大多数智能体框架都提供了回调（Callback）或生命周期钩子（Hook）机制。这是最优雅、侵入性最低的方式。

  • 在LangChain中，你可以自定义一个 BaseCallbackHandler ，在 on_chain_start , on_chain_end , on_tool_start , on_tool_end 等事件中，记录下所有的输入、输出、耗时等信息。
  • 在AutoGen中，可以通过注册消息拦截函数，捕获所有智能体之间的对话消息。
  • 实现示例（伪代码思路） ： 
    class EvolutionDataCollector(BaseCallbackHandler):
    def on_chain_start(self, serialized, inputs, **kwargs):
        trace_id = generate_unique_id()
        self.current_trace = {
            “id”: trace_id,
            “chain_type”: serialized.get(“id”, [“last”])[-1],
            “input”: inputs,
            “start_time”: time.time(),
            “steps”: []
        }
        self.trace_stack.append(self.current_trace)

    def on_tool_end(self, output, **kwargs):
        tool_step = {
            “type”: “tool”,
            “name”: kwargs.get(“tool_name”),
            “input”: kwargs.get(“tool_input”),
            “output”: output,
            “latency”: time.time() - self.tool_start_time
        }
        self.current_trace[“steps”].append(tool_step)

    def on_chain_end(self, outputs, **kwargs):
        self.current_trace[“output”] = outputs
        self.current_trace[“end_time”] = time.time()
        self.current_trace[“total_latency”] = self.current_trace[“end_time”] - self.current_trace[“start_time”]
        # 将完整的trace存入数据库（如PostgreSQL, Elasticsearch, 或专门的向量数据库如Weaviate用于后续相似性分析）
        save_to_database(self.current_trace)
        self.trace_stack.pop()

    注意事项 ：确保你的数据收集是异步的或对性能影响极小。不要在主逻辑线程中进行复杂的数据库写入操作，应该将数据推送到一个内存队列（如Redis Stream），由后台工作线程消费入库。

2. 日志聚合 如果框架不支持精细的回调，或者智能体是黑盒服务（如直接调用某个API），那么可以通过标准化、结构化的日志输出进行收集。要求工作智能体在所有关键决策点输出符合特定JSON格式的日志，然后使用日志收集系统（如Fluentd, Logstash）进行聚合和解析。

3. 代理层包装 在最外层包装一个“代理层”，所有对工作智能体的请求都先经过这个层。这个层负责转发请求、接收响应，并同时记录下完整的交互上下文。这种方式通用性强，但增加了单点故障和延迟。

数据存储设计 ：收集到的数据建议存储在两个地方：

  • 关系型数据库（如PostgreSQL） ：存储结构化的元数据（会话ID、时间戳、用户ID、最终结果、性能评分）。
  • 向量数据库（如Chroma, Pinecone, Weaviate） ：存储非结构化的核心内容，如用户问题、智能体回答、工具调用参数。这为后续基于语义的相似案例检索和分析提供了便利。例如，当顾问发现某个问题处理失败时，可以快速在向量数据库中检索出历史上所有语义相似的问题，看看智能体是如何处理的，成功率如何。

3.2 分析引擎：让LLM成为你的首席诊断官

这是整个系统的智慧核心。我们的目标是让LLM像一位经验丰富的架构师一样，阅读智能体的“病历”（交互轨迹），并给出诊断。

1. 构建诊断提示词（Prompt） 提示词的质量直接决定分析结果的好坏。一个好的诊断提示词应该包含以下几个部分：

  • 角色设定 ：明确告诉LLM它要扮演什么角色（例如，“你是一位资深的AI智能体性能优化专家”）。
  • 任务背景 ：说明被分析智能体的主要职责和领域。
  • 输入数据格式说明 ：清晰地告诉LLM你会提供什么数据，每个字段是什么意思。提供示例。
  • 分析框架与输出格式要求 ：这是最关键的部分。你需要引导LLM按照一个结构化的思路进行分析，并强制它输出格式化的结果（如JSON），以便程序后续处理。
    • 分析维度 ：可以包括：任务理解准确性、工具使用合理性、推理逻辑连贯性、信息完整性、效率（步骤冗余度）、安全性/合规性等。
    • 输出格式 ：要求LLM输出如 {“issue_summary”: “...”, “root_cause”: “...”, “confidence”: 0.9, “improvement_suggestions”: [“...”, “...”]} 。

2. 实现分析服务 分析服务可以是一个独立的微服务，它从经验池中获取一批待分析的交互轨迹，调用LLM API进行分析，并将结果存储回数据库。

  • 批处理与速率限制 ：考虑到成本和延迟，通常采用异步批处理的方式。需要严格遵守LLM供应商的速率限制（Rate Limit）。
  • 缓存机制 ：对于完全相同的输入，分析结果应该是相同的。可以引入缓存（如Redis），对交互轨迹的哈希值进行缓存，避免重复分析，节省成本。
  • 降级策略 ：当主要LLM服务（如GPT-4）不可用或超时时，应有降级方案，例如切换到更便宜、更快的模型（如Claude Haiku， GPT-3.5-Turbo）进行初步分析，或者仅执行基于规则的简单诊断。

3. 从个案分析到模式聚合 单个案例的分析很有用，但更有价值的是发现 共性模式 。分析引擎在积累了一定量的诊断结果后，应该能进行聚合分析。

  • 聚类分析 ：将所有诊断出的“问题根因”进行文本嵌入（Embedding），然后进行聚类。你会发现，可能40%的问题都归属于“工具选择逻辑模糊”这个大类。
  • 关联分析 ：分析问题类型与任务类型、输入复杂度、所用工具之间的关联关系。例如，“代码生成任务在涉及网络请求时，容易产生不安全的代码建议”。
  • 趋势分析 ：跟踪特定问题类型随时间的变化频率，是增加了还是减少了，以此判断之前的优化措施是否有效。

3.3 建议生成与实验评估

基于分析结果生成建议，同样可以借助LLM。你可以将诊断报告（包括原始交互轨迹和问题分析）输入给另一个LLM调用，并提示它：“基于以上诊断，请为该智能体提出3条具体、可操作的改进建议，每条建议需说明预期收益和实施复杂度（高/中/低）。”

生成的建议需要被评估。最可靠的方法是在一个与生产环境隔离的 沙箱环境 中进行测试。

1. 构建测试沙箱

  • 复制一份生产环境的工作智能体代码和配置。
  • 准备一个 高质量的评估数据集 。这个数据集应该覆盖智能体的主要任务场景，并包含标准答案或评估标准。它可以是历史对话中精选的用例，也可以是人工构建的测试集。
  • 在沙箱中，创建智能体的两个版本：A版本（原始版）和B版本（应用了建议的修改版）。

2. 自动化评估流水线

  • 使用相同的评估数据集，并行运行A和B两个版本。
  • 自动化收集关键指标。对于客观任务（如代码执行、数学计算），可以自动化比对结果。对于主观任务（如文案创作、对话质量），可以：
    • 使用评估LLM ：设计提示词让另一个LLM（作为裁判）对A和B的回答进行评分，并给出理由。虽然不完全可靠，但一致性较高。
    • 人工评估抽样 ：对关键场景或差异较大的结果，进行小规模的人工评估。
  • 对比A和B的各项指标（准确率、满意度、平均响应时间、Token消耗等），进行统计学显著性检验，确保观察到的差异不是随机波动。

3. 生成评估报告 自动化评估流水线最终应生成一份详细的报告，内容包括：

  • 改进建议的描述。
  • A/B测试的详细数据对比。
  • 性能提升的百分比和统计置信度。
  • 资源消耗的变化（成本影响）。
  • 潜在的风险提示（如在某些边缘案例上的性能回归）。 这份报告是提交给人类决策者进行审批的核心依据。

4. 实战部署与运维考量

理论很美好，但把这样一个系统真正跑起来，并持续产生价值，会遇到许多工程和运维上的挑战。这部分分享一些从零搭建时需要特别注意的“坑”。

4.1 基础设施与工具链选型

一个完整的进化顾问系统是一个中等复杂度的数据系统，涉及数据采集、存储、处理、分析和展示。

1. 技术栈建议

  • 智能体框架 ：根据你的工作智能体来定。LangChain生态丰富，AutoGen擅长多智能体协作，LlamaIndex长于检索。选择你团队最熟悉的。
  • 数据管道 ：考虑使用 Apache Kafka 或 Redis Stream 作为实时数据总线。观察模块将数据作为事件发布到流中，后续的分析、存储等消费者各自订阅。这解耦了系统组件，提高了可扩展性。
  • 存储 ：
    • 时序数据 ：智能体的性能指标（QPS、延迟、错误率）适合存入 InfluxDB 或 TimescaleDB （基于PostgreSQL的时序扩展），便于做时间序列分析和监控告警。
    • 交互轨迹 ：结构化的元数据存 PostgreSQL 。非结构化的对话文本、工具输入输出，存入 向量数据库 （如Chroma用于原型和中小规模，Weaviate或Pinecone用于生产级）以便语义检索。
    • 分析结果与建议 ：存回 PostgreSQL 或 MongoDB （如果结构灵活）。
  • 计算与编排 ：分析任务（尤其是调用LLM）是计算密集且耗时的。使用 Celery 或 Dramatiq 作为分布式任务队列，将分析任务异步化。使用 Apache Airflow 或 Prefect 来编排周期性的聚合分析、报告生成任务。
  • 可视化与告警 ：使用 Grafana 连接你的时序数据库，绘制智能体各项指标的趋势图。设置告警规则，当关键指标（如错误率）异常时通知团队。分析报告可以通过内部Wiki、邮件或Slack机器人推送。

2. 成本控制 LLM API调用是主要成本。必须精打细算：

  • 采样分析 ：不必分析每一条交互。可以按一定比例（如10%）随机采样，或者只分析失败/低评分的会话。
  • 缓存一切 ：如前所述，对相同的输入进行缓存。
  • 模型分级 ：对于实时性要求不高的深度分析，使用GPT-4。对于实时监控和初步过滤，使用更便宜的模型如GPT-3.5-Turbo或Claude Haiku。
  • 设置预算与监控 ：为LLM API使用设置每日/每月预算，并监控消耗情况。

4.2 核心挑战与应对策略

1. 评估的“评估”问题（Meta-Evaluation） 如何判断进化顾问自己给出的分析和建议是好的？这是一个元问题。如果顾问的诊断是错的，建议是无效甚至有害的，那么整个系统就失去了意义。

  • 策略 ：建立“黄金标准”测试集。人工精心标注一批涵盖各种典型成功和失败案例的交互轨迹，并给出专家级的诊断和改进建议。定期用这套“黄金标准”去评估进化顾问的输出，计算其与人工标注的吻合度（如通过LLM判断建议的相关性、准确性）。这可以作为监控进化顾问自身性能的核心指标。

2. 避免局部最优与“进化漂移” 智能体可能在顾问的指导下，针对当前遇到的任务类型不断优化，却逐渐丧失了处理其他类型任务的能力（过拟合）。或者，为了提升某个指标（如响应速度），而牺牲了另一个重要指标（如回答质量）。

  • 策略 ：在评估体系中引入 多样性指标 和 多目标权衡 。测试集必须保持任务类型的多样性。评估函数不能是单一指标（如准确率），而应该是一个综合考虑质量、速度、成本、安全性的加权分数。定期在全新的、未曾见过的任务类型上测试智能体，检查其泛化能力是否下降。

3. 安全与可控性 这是最高优先级的问题。绝不能让进化顾问在未经严格审查的情况下，直接修改生产环境智能体的核心逻辑或提示词，尤其是涉及价值观、安全边界的内容。

  • 策略 ：
    • 严格的权限隔离 ：进化顾问只有对沙箱环境的“读/写”权限，对生产环境只有“读”权限。
    • 人类在环（Human-in-the-loop） ：所有对生产环境的变更，必须经过人类审核。系统可以提供清晰的对比报告和决策依据，但按钮必须由人来按。
    • 变更回滚机制 ：任何部署都必须有快速、一键回滚到上一个稳定版本的能力。
    • 敏感词与红线检测 ：在建议生成和评估环节，加入对输出内容的过滤和检测，防止生成违反安全政策的修改建议。

4. 系统的可解释性与信任 如果进化顾问只是一个黑盒，给出的建议难以理解，开发团队将不敢采纳。

  • 策略 ：在设计分析报告和建议时， 极度重视可解释性 。要求LLM在给出诊断时，必须引用交互轨迹中的具体片段作为证据（“在第三步，用户问了X，智能体回答了Y，这里存在Z问题”）。建议必须具体、可操作，而不是“优化提示词”这样的模糊表述，而应该是“在系统提示词的第二段，增加一条约束：‘在提供医疗建议前，必须明确声明自己不是医生，建议仅供参考’”。

5. 未来展望与进阶思考

当我们构建并运行起一个基本的进化顾问系统后，可以朝着哪些更有想象力的方向探索？

1. 多智能体协作进化 当前的模式是一个顾问对应一个工作智能体。更复杂的场景是多个智能体协作完成一项任务（例如，一个负责规划，一个负责编码，一个负责测试）。进化顾问可以观察整个协作网络的交互，诊断出协作接口的问题、信息传递的瓶颈，并提出优化整个团队工作流的建议，比如调整通信协议、增加一个负责信息核对的“审核员”角色。

2. 基于种群与遗传算法的进化 这更贴近“进化”的本意。我们可以维护一个“智能体种群”，其中包含同一个任务的不同变体（不同的提示词、不同的工作流、甚至不同的基础模型）。让它们都在环境中运行，进化顾问根据它们的表现（适应度）进行“选择”，让表现好的“个体”产生更多的“后代”（通过交叉、变异提示词或工作流生成新变体），淘汰表现差的。通过多代迭代，可能自动涌现出人类未曾想到的优秀设计。

3. 将进化能力内化：自反思智能体 终极形态或许是让“进化顾问”的能力不再是外部系统，而是内化到每一个工作智能体之中。智能体在每次任务执行后，都进行一段“自我反思”：我哪里做得好？哪里可以改进？并基于反思微调自己的下一次行为。这相当于给智能体赋予了“元认知”能力。虽然当前LLM的上下文长度和长期记忆限制使得完全内化还很困难，但可以设计一种轻量级的、基于会话历史的即时反思机制。

构建一个 agent-evolution-advisor 绝非易事，它涉及软件工程、机器学习、数据分析、人机交互等多个领域的知识。但从另一个角度看，它为我们管理、理解和改进日益复杂的AI智能体系统提供了一个强有力的框架和工具。它迫使我们去思考如何量化智能体的“好坏”，如何定义“进化”的方向，以及如何在赋予AI更多自主性的同时，牢牢握住安全的缰绳。这个项目更像是一个起点，一个关于“如何建造能够建造工具的工具”的持续探索。

# AI智能体
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区