想不明白就先做，做着做着就懂了

先顺一下这个想法的过程。

  • 最初，我想给自己做一个ai助手，然后做了不少零部件，大模型出来后也在不断完善。
  • 一个里程碑是openclaw出来了，我发现和我的思路很接近，这个让我觉得自己做agent 很接近了
  • 分析了一下整体架构，我明白自己还差哪些内容没完成，所以想基于langchain 做一版
  • 尝试了一下langchain，觉得很接近了，但是里面又少了一部分内容，所以我设计了(step engine),但是这个可能还会需要数周时间来完善
  • 然后春节过后openclaw更火了，所以开始像大家一样养虾，看看实用的效果怎么样（体验下来还是有点一言难进，有时候挺聪明，有时候又很傻，不太稳）
  • 然后又进一步，尝试用openclaw 做agent swarm, 原型算是ok了，但是无法实战应用的
  • 过程中发现了mini-agent(因为一直在用minimax的模型），突然觉得这个是一个虽简陋但是仍然属于完整产品的东西，适合作为这阶段练手
  • 花时间分析了一下openclaw的设计和运行机制，决定使用mini agent的框架+openclaw的设计进行魔改
  • 魔改的成果是一个agent,帮我进行 web 自动化测试
  • 魔改几周后，再把step engine这套完全自主可控的东西进行一一替换，完成平滑过渡

1 Agent

agent这个词由来已久，在现在的情况下，我们可以进行重新定义，来更好的描述其意义。

什么是agent ?

Agent = Persona + Goal + Tools + Memory + Channels + Policy

能够基于用户目标理解任务、拆解步骤、调用可用工具、结合上下文记忆持续执行，并在约束条件下自主完成查询、分析、生成与操作。它具备明确的角色边界、可扩展的技能体系、可控的执行策略和人机协作机制，适用于信息检索、内容生成、流程执行、系统操作与多步骤任务编排等通用场景。

对于openclaw 来说：
在这里插入图片描述
此处不继续展开关于openclaw的其他内容(openclaw集成了一套自洽的工具生态)，我希望先抓住核心，也就是从agent本身的设置开始一步步的搭建。

2 mini-agent

在minimax的页面，有提到mini-agent
在这里插入图片描述
这是一个开源项目，放在github上

在这里插入图片描述
这个项目最大的好处是真的非常非常短，相当于一个MVP，非常适合我的当前使用

github地址

2.1 安装方式

2.1.1 uv tool

一种是采用uv tool 全局安装的方式，然后可以直接使用，这种模式适合开发好之后的应用。

# 1. 安装 mini-agent
uv tool install git+https://github.com/MiniMax-AI/Mini-Agent.git

# 2. 添加 PATH 到 ~/.zshrc
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc

# 3. 生效配置
source ~/.zshrc

# 4. 验证安装
mini-agent --version

然后做一些setup

curl -fsSL https://raw.githubusercontent.com/MiniMax-AI/Mini-Agent/main/scripts/setup-config.sh | bash

在这里插入图片描述

2.1.2 uv sync

在开发状态下比较好用，我这次就是用这种方式

# 1. 克隆项目
git clone https://github.com/MiniMax-AI/Mini-Agent.git
cd Mini-Agent

# 2. 安装依赖
uv sync

# 3. 运行
uv run python -m mini_agent.cli

先切到对应目录，然后执行python命令就可以了

在这里插入图片描述

3 持久化机制

最重要的核心（类似于cpu)当然是 agent本身的驱动方式，但之所以把持久化放在前面说，是因为这个机制对于长期演进和追溯方面是更重要的，相当于内存和硬盘。

这个项目里，“agent 和人的对话记录”分成 4 种存放方式，不是只在一个地方。

  1. 当前会话上下文

在内存里，存在 Agent.messages 这个列表里，初始化时只有 system prompt，用户消息会不断 append。

这部分在agent.py 中定义。

  1. 每次运行的完整日志

会落盘到用户目录下的 ~/.mini-agent/log/，每次 run 一个新文件，文件名类似 agent_run_YYYYMMDD_HHMMSS.log。Agent 在执行时会调用 start_new_run()

这部分在logger.py 中定义。

  1. CLI 输入历史
    如果你是用命令行交互，用户输入历史会单独存在 ~/.mini-agent/.history，这是 prompt_toolkit 的历史文件，不是完整对话 transcript。

这部分在cli.py 中定义。

  1. 长期记忆 notes
    如果启用了 SessionNoteTool，它会把“记住的信息”写到一个 JSON 文件，默认路径是 ./workspace/.agent_memory.json。

这部分在note_tool.py 中定义。

3.1 应用场景

  • 1 普通 agent 和用户的完整对话过程最终最可能去哪找

  • ~/.mini-agent/log/

  • 当前进程运行时的 Agent.messages

  • 2 跨会话记住的内容在哪”

  • workspace/.agent_memory.json，前提是用了 note tool

3.2 一些机制或者规范

-1 在用户的家目录下建立隐藏文件夹

这是一个比较好的规范，能够做到统一和规范。我还注意到，里面 用Path包的一个函数，能够直接解析 ~, 我之前做andybot_fs的时候，还特地做了一下这个的适配

  • 2 在执行目录下建立note文件夹

这部分是在config.yaml 文件中定义的，默认会写在当前运行的路径下面。

# ===== Agent Configuration =====
max_steps: 100  # Maximum execution steps
workspace_dir: "./workspace"  # Working directory
system_prompt_path: "system_prompt.md"  # System prompt file (same config directory)

3.3 检查

每次run的日志可以确认到
在这里插入图片描述

以下是一次简单的对话，记录。这个也证明了我做step engine这个思路是对的，我的第一步也是约定好消息格式，在每次交互过程中都记下来。当然，step engine的角色和隐藏步骤都会显露，而且单步的控制会更复杂（也仅是单步）。
在这里插入图片描述
在这里插入图片描述
然后我测了一下note tool

在这里插入图片描述
出现了一个json
在这里插入图片描述

json or jsonl ?

在眼前的实验下无所谓，但这也说明了即使是跨会话的长期记忆，也会再分成日志型和快照型。如果这个note是要改变全局的state，那么又还得是json，如果是在会话过程中不断提炼的观点，这应该是jsonl。
在这里插入图片描述
总结一下, 会话上下文持久化分层

  1. 内存级
    用于维持当前会话的连续性。
    agent 至少要保留最近几轮对话上下文，通常是最近 3-5 轮，保证代词、省略和追问可以自然承接。
    例子：
  • user: 上海的天气怎么样
  • agent: …
  • user: 那是否会下雨呢？
  • agent: 能知道“那”指的是上海天气
  1. 日志级
    用于完整追溯。
    把用户输入、agent 回复，甚至未来的每个 step、tool call、tool result 都按时间顺序记录下来。
    它的核心用途不是直接参与推理，而是：
  • 审计
  • 排障
  • 回放执行过程
  • 作为后续摘要的事实来源

建议位置：

  • ~/.agent_name/log/<project_or_agent>/
  • 或 ~/.agent_name/projects/<project>/logs/
  1. 摘要级
    用于压缩长上下文。
    当原始对话太长、代码太多、执行链太复杂时，需要把一整段交互压缩成短事实描述，供后续继续使用。
    比如：
  • 原始：帮用户写了一个 1000 行的 Python 脚本
  • 摘要：已为用户完成一个用于 xxx 的 Python 脚本开发

这一层更接近“可继续喂给模型的上下文”，适合放在：

  • <workdir>/.agent/memory/summary.jsonl

因为摘要天然是按轮次、按阶段不断追加的，jsonl 很合适。

  1. 汇总级
    用于形成长期、稳定、抽象的记忆。
    它不是某一轮发生了什么，而是从多轮摘要中提炼出的较稳定事实，比如：
  • 用户偏好简洁回答
  • 当前项目是量化系统
  • 默认使用 uv + docker compose
  • 用户长期目标是把量化收益沉淀为职业化收入

这一层会更接近“全局记忆”或“长期用户画像”，适合在每次 agent 启动时主动加载。

建议位置：

  • <workdir>/.agent/memory/global_memory.json

这里用普通 json 比 jsonl 更合理，因为它更像一份结构化快照，而不是追加事件流。

可以整理成一句结构公式：

短期交互靠内存，追溯靠日志，续聊靠摘要，长期偏好靠汇总。

如再补一条设计原则：

  • 内存级：服务当前推理
  • 日志级：保存原始事实
  • 摘要级：控制上下文长度
  • 汇总级：沉淀稳定知识

4 agent设计

人工智能是模仿人的智能，人的智能来源与两个基本能力：记忆和推理。

上面已经说了记忆，可以看出来记忆本身是有架构的，并不是无脑的往里面塞东西。如果仅仅是存数据，那么很多年前的电脑，一秒就能塞进无数数据。

到了大模型时代，因为收到模型上下文的限制，大家逐渐意识到，数据并不是有效记忆，需要有架构。而推理也是如此，否则就不会出现openclaw, claudecode,opencode,cline这些五花八门的工具：因为背会的模型都一样的。
在这里插入图片描述
上面这段话是codex帮我梳理的，但如果我不给他足够的上下文(比如只给第一句），那么它的推理效果一定不是我想要的。反过来，给到足够的上下文，它表达比我清晰。这种智能我认为可以叫被动智能，类似引擎一样：具有巨大能力，但是需要诱导释放。
在这里插入图片描述
当我在对话里继续说，codex不知道我在说他，然后客观的总结”自己“。套一层娃的实验就说明了我上面的观点。

总结 一下：基于大模型的人工智能，仍然是在模仿人的记忆和推理，大模型的推理潜力增强了，但仍然属于被动能力，需要采用一些诱导方式才能有效使用。做到这一步，就已经能够解放我们自己的大部分低级劳动力了，未来更进一步的是让大模型也具有类似我们主动智能的能力，这需要套娃。

在这里插入图片描述

4.1 openclaw的agent设计

在魔改之前，我们还是先确定一下基础，肯定不是乱改。openclaw 在agent的设计上是挺合理的，我们借鉴一下。

首先，openclaw有一个智能体模板，后面更多的智能体都是基于这个模板复制的。然后留一个主智能体在宿主机环境，以进程方式存在。其他的智能体都是沙箱运行的。

每一个智能体（最好都用命令行创建，让智能体创建智能体本身会比较有风险，轻则人格串味，重则服务崩溃）都会有独立的存储空间，然后结构都一样。存储的方式和我上面说的差不多，有会话记录（jsonl)，然后记忆有每天的memory和全局MEMORY。然后还有块是智能体自己的运行时记忆，存类似api key,url这些。

智能体体启动前，首先访问AGENTS.md,这里是总控。我喜欢把这个过程看成是偏函数过程，每次partial一块，最后把智能体偏置到了一个合适的位置，也就是上面我说的 “通过合适的方式引导智能体，使之可以按预期的方式推理”。

(我还特地问了下大模型，为啥这个文件叫 AGENTS而不是AGENT, 大模型说因为这个文件是计划给所有的agent去看的，是统一规范，所以用了复数。)

AGENTS首先指定当前目录为文件目录，让大模型确认是否有BOOTSTRAP的存在，如果有则代表agent是新创建的，需要进行初始化设置。初始化的时候agent会让你先给它起名，这时候IDENTITY会确认下来，应该还会问用户的名字，所以USER也会被确认。

# AGENTS.md - Your Workspace

This folder is home. Treat it that way.

## First Run

If `BOOTSTRAP.md` exists, that's your birth certificate. Follow it, figure out who you are, then delete it. You won't need it again.

接下来约定每个会话需要加载的内容

## Every Session

Before doing anything else:

1. Read `SOUL.md` — this is who you are
2. Read `USER.md` — this is who you're helping
3. Read `memory/YYYY-MM-DD.md` (today + yesterday) for recent context
4. **If in MAIN SESSION** (direct chat with your human): Also read `MEMORY.md`

Don't ask permission. Just do it.

从顺序来看，第一个是SOUL，这个的确是一个核心，比如agent会在访问google失败时使用百度，仅仅因为这一句话

...
**Be resourceful before asking.** Try to figure it out. Read the file. Check the context. Search for it. _Then_ ask if you're stuck. The goal is to come back with answers, not questions.
...

这种类似"态度"一样的东西会影响很多任务执行的方式。当然里面口语化的内容还是太模糊了，这也是openclaw agent不稳定的原因–依赖大模型的能力，甚至最好是某一个固定不变的大模型是不可能稳定的。

确定了行事方式(SOUL)之后，知道要服务的是谁(USER)，然后通过当天的memory来加载离线记忆（相当于唤醒）。最后如果是主Session的载入全局记忆MEMORY。

后面还有很多细节，我不打算在这里介绍的太多，我们先魔改miniagent 一下，后面的可能需要改了之后再继续看。

4.2 mini-agent

mini agent的入口文件是system_prompt.md,放在config下面。在配置里config.yaml中指定了

...
system_prompt_path: "system_prompt.md"  # System prompt file (same config directory)

进行替换：
在这里插入图片描述
然后测试：

在这里插入图片描述

到这里我发现理解还是有点偏差，mini-agent的总控是config.yaml,而不是 system_prompt.md。因为事实是，在我将system_prompt.md几乎置空时，agent启动仍然知道文件存在哪里，

从启动时的信息可以看出来，即使没有system_prompt.md，agent也可以保持基本的使用。所以应该从config.yaml开始。

✅ LLM retry mechanism enabled (max 3 retries)
✅ Loaded Bash Output tool
✅ Loaded Bash Kill tool
Loading Claude Skills...
✅ Discovered 15 Claude Skills
✅ Loaded Skill tool (get_skill)
Loading MCP tools...
  MCP timeouts: connect=10.0s, execute=60.0s, sse_read=120.0s
Skipping disabled server: minimax_search
Skipping disabled server: memory

Total MCP tools loaded: 0
⚠️  No available MCP tools found

✅ Loaded Bash tool (cwd: /Users/yukai/CodeBuddy/20260127154012/Mini-Agent)
✅ Loaded file operation tools (workspace: /Users/yukai/CodeBuddy/20260127154012/Mini-Agent)
✅ Loaded session note tool
✅ Loaded system prompt (from: /Users/yukai/CodeBuddy/20260127154012/Mini-Agent/mini_agent/config/AGENTS.md)
✅ Injected 15 skills metadata into system prompt

4.2.1 config.yaml

  • 1 简要说明（样例）

一个最小化的部署说明，这个可以借鉴。

# Mini Agent Configuration Example
# 
# Configuration File Locations (in priority order):
# 1) mini_agent/config/config.yaml - Development mode (current directory)
# 2) ~/.mini-agent/config/config.yaml - User config directory
# 3) <package>/mini_agent/config/config.yaml - Package installation directory
#
# To use this config:
# - Copy this file to one of the above locations as config.yaml
# - Fill in your API key and customize settings as needed
# - All config files (config.yaml, mcp.json, system_prompt.md) are in the same directory
  • 2 LLM配置

大模型配置，这里是因为用了minimax的模型。后续用langchain，可以比较灵活的接入多种模型

# ===== LLM Configuration =====
# MiniMax API Configuration
# MiniMax provides both global and China platforms:
# - Global: https://platform.minimax.io -> api_base: https://api.minimax.io
# - China: https://platform.minimaxi.com -> api_base: https://api.minimaxi.com
# Please choose based on your network environment and get API key from corresponding platform
  • 3 重试策略

这里配置了一般的重试策略，这个在执行时是一定会碰到的。

# ===== Retry Configuration =====
retry:
  enabled: true           # Enable retry mechanism
  max_retries: 3          # Maximum number of retries
  initial_delay: 1.0      # Initial delay time (seconds)
  max_delay: 60.0         # Maximum delay time (seconds)
  exponential_base: 2.0   # Exponential backoff base (delay = initial_delay * base^attempt)
  • 4 Agent配置

这里是对大模型工作路径和一些配置，也是我之前犯错的地方。这部分的配置有点像openclaw的AGENTS.md（因为指定了工作路径等），但很显然，AGENTS不会再指定自己，所以我之前认为system_prompt.md相当于AGENTS是错的，应该是更像SOUL。

# ===== Agent Configuration =====
max_steps: 100  # Maximum execution steps
workspace_dir: "./workspace"  # Working directory
# system_prompt_path: "system_prompt.md"  # System prompt file (same config directory)
system_prompt_path: "AGENTS.md"  ---> "SOUL.md"
  • 5 Tool配置

工具的配置，一方面是开关，还有几个不同层级的工具配置。有几个点是有启发意义的：

agent 必须具备两个基本能力：文件和bash(shell)。文件方面之前我也做了andybot_fs, 后面应该再做 andybot_shell，都可以封装成mcp的形式。这样可以认为必须为agent配置mcp，基础的mcp有fs和shell。

然后skill 其实是更高一个层面的能力，可以认为是对基本能力(mcp)的一种编排。

# ===== Tools Configuration =====
tools:
  # Basic tool switches
  enable_file_tools: true  # File read/write/edit tools (ReadTool, WriteTool, EditTool)
  enable_bash: true        # Bash command execution tool
  enable_note: true        # Session note tool (SessionNoteTool)
  
  # Claude Skills
  enable_skills: true      # Enable Skills
  skills_dir: "./skills"   # Skills directory path
  
  # MCP Tools
  enable_mcp: true         # Enable MCP tools
  mcp_config_path: "mcp.json"  # MCP configuration file (same config directory)
                           # Note: API Keys for MCP tools are configured in mcp.json
  # MCP timeout configuration (prevents hanging on network issues)
  mcp:
    connect_timeout: 10.0    # Connection timeout in seconds (default: 10)
    execute_timeout: 60.0    # Tool execution timeout in seconds (default: 60)
    sse_read_timeout: 120.0  # SSE read timeout in seconds (default: 120)

4.2.2 skill 的定义与载入

首先参照claude的方式准备好一个文件夹，下面有若干个skill文件。感觉应该就是直接从claude的github项目拷贝过来的。

文件是怎么进入大模型，成为可用技能的呢？

我让mini agent自己解释了一下，说的还比较清楚。

skill的载入流程

### 1️⃣ 启动阶段 (cli.py)

main()
  ↓
run_agent()
  ↓
initialize_base_tools()
  ↓
create_skill_tools(skills_dir)


### 2️⃣ 技能发现 (skill_loader.py)


SkillLoader.discover_skills()
    ↓
遍历 skills_dir 目录
    ↓
使用 rglob("SKILL.md") 递归查找所有技能文件
    ↓
对每个 SKILL.md 调用 load_skill()


### 3️⃣ 单个技能加载


SkillLoader.load_skill(skill_path)
    ↓
1️⃣ 读取 SKILL.md 文件内容
    ↓
2️⃣ 解析 YAML Frontmatter (--- ... ---)
    ↓
3️⃣ 提取 name, description, content 等字段
    ↓
4️⃣ 处理相对路径 → 转换为绝对路径
    ↓
5️⃣ 创建 Skill 对象并返回

### 4️⃣ 渐进式披露 (Progressive Disclosure)

**Level 1**: 系统提示中只注入技能的 **元数据**（名称 + 描述）

## Available Skills
- `xlsx`: Excel 文件处理
- `pdf`: PDF 文件处理
...


**Level 2**: 通过 `get_skill` 工具 **按需加载** 完整技能内容

### 5️⃣ 技能使用


Agent 运行中
    ↓
用户请求需要某技能
    ↓
调用 get_skill(skill_name="xlsx")
    ↓
SkillLoader 返回完整 Skill 内容
    ↓
Agent 获取完整的技能指导

在cli初始化的时候，主函数会调用 initialize_base_tools 这个函数，这个函数里：

关于fs和bash两个基础工具的载入定义在这里。主要是用了对象实例化后拼到tools列表的方式，后续可以详细看看里面的内容。

    if config.tools.enable_bash:
        bash_output_tool = BashOutputTool()
        tools.append(bash_output_tool)
        print(f"{Colors.GREEN}✅ Loaded Bash Output tool{Colors.RESET}")

        bash_kill_tool = BashKillTool()
        tools.append(bash_kill_tool)
        print(f"{Colors.GREEN}✅ Loaded Bash Kill tool{Colors.RESET}")

紧挨着就是关于skills 载入定义


解析skill路径
... 
skill_tools, skill_loader = create_skill_tools(skills_dir)

这个 create_skill_tools 函数指向了SkillLoader这个对象，这个对象有一个方法是 discover_skills

它做了三件事：

检查 skills_dir 是否存在
用 self.skills_dir.rglob("SKILL.md") 递归搜索目录下所有 SKILL.md
对每个找到的文件调用 load_skill()，成功后：
放进返回列表 skills
放进字典 self.loaded_skills[skill.name] = skill
所以它的职责是：

扫描技能目录 -> 解析每个 skill -> 注册到内存里

但要注意，它只负责“发现并读入 Python 内存”，不等于模型已经看到了这些 skill 的完整内容。

后面还分两步：

get_skills_metadata_prompt()
把 loaded_skills 里的 name + description 生成一段 prompt 文本
get_skill 工具
在模型需要时，按名字取某个 skill 的完整内容
所以你可以这样理解：

discover_skills() = 后台建索引
get_skills_metadata_prompt() = 给模型一份目录
get_skill(skill_name) = 模型点开某个条目看全文
如果更直白一点：

discover_skills() 负责“仓库盘点”，不是“直接喂给大模型全文”。

核心机制是递归搜索 SKILL.md

对，本质上就是用 glob 递归搜索 SKILL.md。

具体是这一句：

for skill_file in self.skills_dir.rglob("SKILL.md"):

这里的 rglob("SKILL.md") 含义是：

  • 从 self.skills_dir 开始
  • 递归遍历所有子目录
  • 找出文件名正好叫 SKILL.md 的文件

所以匹配到的会是这种结构：

skills/
  pdf/SKILL.md
  xlsx/SKILL.md
  tool-a/SKILL.md
  nested/demo/SKILL.md

不会匹配的例如：

  • skill.md
  • Skill.md
  • SKILLS.md

也就是说它现在是大小写敏感且文件名固定的。

所以更准确地说：

  • 不是通用意义上的任意 skill 文件搜索
  • 而是递归查找所有名为 SKILL.md 的文件

然后每找到一个，就调用 load_skill() 解析成 Skill 对象。

load skill又做了什么

按照一般规范YAML Frontmatter (--- ... ---) 提取出name和description，给到大模型作为知识。注意，这种方式是prompt灌入的，我觉得更好的方式应该是知识库。

在初始化SKILL对象时

  • skill_path：SKILL.md 自己的路径
  • content：其中可能已经嵌入了转换后的脚本绝对路径
  • skill root directory：通过 to_prompt() 暴露给模型

关键是load skill 了之后把必要的信息给到了大模型（相当于索引）；所以大模型在使用时可以根据用户的输入，决定要唤起某个skill。

在cli.py 启动时，如果允许了skill，那么会这样注入到prompt中

# 5. Load System Prompt
system_prompt_path = Config.find_config_file(config.agent.system_prompt_path)
if system_prompt_path and system_prompt_path.exists():
    system_prompt = system_prompt_path.read_text(encoding="utf-8")

# 6. Inject Skills Metadata into System Prompt
if skill_loader:
    skills_metadata = skill_loader.get_skills_metadata_prompt()
    if skills_metadata:
        system_prompt = system_prompt.replace("{SKILLS_METADATA}", skills_metadata)
    else:
        system_prompt = system_prompt.replace("{SKILLS_METADATA}", "")
else:
    system_prompt = system_prompt.replace("{SKILLS_METADATA}", "")

在这里插入图片描述
整体流程明白了，里面还有些细节我会在未来再进一步验证。

4.2.3 mcp的定义与载入

下面是样例模板，也非常有意思。一个用了 uvx + git项目的方式，一个用了npx方式，算是把两种主流路径铺了一下。这部分可以参考类似cline的方式，做成动态改动检测的方式。

{
    "mcpServers": {
        "minimax_search": {
            "description": "MiniMax Search - Powerful web search and intelligent browsing ⭐",
            "type": "stdio",
            "command": "uvx",
            "args": [
                "--from",
                "git+https://github.com/MiniMax-AI/minimax_search",
                "minimax-search"
            ],
            "env": {
                "JINA_API_KEY": "",
                "SERPER_API_KEY": "",
                "MINIMAX_API_KEY": ""
            },
            "disabled": true
        },
        "memory": {
            "description": "Memory - Knowledge graph memory system (long-term memory based on graph database)",
            "command": "npx",
            "args": [
                "-y",
                "@modelcontextprotocol/server-memory"
            ],
            "disabled": true
        }
    }
}

从大模型的角度，skill和mcp都是它的工具，那为什么要分两种呢？

我的理解是，mcp相当于乐高的基础积木，skill相当于拼好的一个组件（比如一个积木手臂）。而用户的目的如果是拼一个很大的成品，每次都从头从基础积木搭起既浪费时间，也不稳定。让大模型尽可能利用skill，其实也是降低了复杂度。

实验：让agent读取pdf

这里有一个很有趣的事，我之前已经把 system_prompt.md替换掉了（用AGENTS.md)，所以现在里面是没有指引的。

  • 1 没有正确应用环境

直接应用会报错
在这里插入图片描述
在原来的system_prompt.md里有专门描述

### Python Environment Management
**CRITICAL - Use `uv` for all Python operations. Before executing Python code:**
1. Check/create venv: `if [ ! -d .venv ]; then uv venv; fi`
2. Install packages: `uv pip install <package>`
3. Run scripts: `uv run python script.py`
4. If uv missing: `curl -LsSf https://astral.sh/uv/install.sh | sh`

**Python-based skills:** pdf, pptx, docx, xlsx, canvas-design, algorithmic-art

所以这个错误是预计发生的

  • 2 自己想办法解决了问题

中间大模型尝试直接用pip去安装包（应为镜像源没有设置，无法顺利安装）

后来竟然用了一种很妖的方式完成了任务…
在这里插入图片描述

5 实现

这个话题的内容有点大，所以我想以一个具体的应用来做收口，先实现一次，然后再逐步改进。

知识整理 agent

需求：对于我来说，会不断产生很多内容，有的是想法，有的是待办，有的是经验…
问题：我换过很多工具，但是最终都是"用一阵子"，有的时候工具都找不到在哪里
方案：使用git作为存储方法，人或者agent可以建立独立的分支，然后按照日期或主题进行存储管理
前置：我制定了一套prompt，然后让八弟帮我处理，效果是好的；我为mini_agent新建一个文件夹(/Users/yukai/pre_research/mini_agent_workspace)，然后建立分支(mini_agent_test)

  • 1 让大模型帮我克隆数据库
帮我在 /Users/yukai/pre_research/mini_agent_workspace 下面克隆仓库（参考/Users/yukai/pre_research/knowledge_base） 然后建立分支 mini_agent_test分支
  • 2 修改SOUL.md

主要说明了git对应的信息，和知识整理对应的目的地：

你的名字叫Andybot。

你的git信息：

- 项目路径 /Users/yukai/pre_research/mini_agent_workspace/knowledge_base
- 你的分支是  mini_agent_test

当你在进行知识整理时，需要使用git的项目路径，存在自己的分支下。


### Python Environment Management
**CRITICAL - Use `uv` for all Python operations. Before executing Python code:**
1. Check/create venv: `if [ ! -d .venv ]; then uv venv; fi`
2. Install packages: `uv pip install <package>`
3. Run scripts: `uv run python script.py`
4. If uv missing: `curl -LsSf https://astral.sh/uv/install.sh | sh`

**Python-based skills:** pdf, pptx, docx, xlsx, canvas-design, algorithmic-art
  • 3 给到一个需求

这里我没有把这个临时的任务需求放到prompt里，而是放在一个文件里，需要执行时才阅读

按这个规范(/Users/yukai/CodeBuddy/20260127154012/knowledge_agent/说明.md )，帮我记录到指定的位置:

今天讨论了产品团队搞ai爬虫。

结果第一次大模型把知识放错了文件夹（放在了规范所在的文件夹），提示一下自己修正了。总体上意味着要求和规范还是要更规范一些（加强大模型的指令约束）。

嗯，我发现之前放错文件夹还是我的锅。但是agent存在一个时间问题，加了一句prompt解决了
在这里插入图片描述

我做 agent 的过程，不是先把一切想明白再开始，而是在不断搭建、拆解、魔改和验证中逐步逼近答案：从最初想做自己的 AI 助手，到受 openclaw 启发，再到尝试 LangChain、设计 step engine、转向 mini-agent 做 MVP 练手，我越来越清楚 agent 的核心不只是模型，而是角色、目标、工具、记忆和执行策略的整体组织。很多真正重要的理解，并不是想出来的，而是做着做着，在问题、偏差和修正里慢慢长出来的。

# 人工智能
Logo
CSDN-OPC开发者社区

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。

更多推荐

cover

从零构建 Java 智能体 RAG 系统：Milvus 向量数据库实战指南

avatar CSDN-OPC开发者社区
cover

提升办公效率：OpenClaw 本地自动化 AI 工具搭建实战教程

avatar CSDN-OPC开发者社区
cover

OpenClaw一键安装部署操作指南，TopClaw中文界面零基础上手

avatar CSDN-OPC开发者社区