1. 用 LLM 构建 Picodevil 的来龙去脉1.1 为什么叫 PicodevilPicodevil 是我在做 LLM 应用开发练习时完成的一个小工具名字取自“Pico”和“devil”。Pico 代表小巧、快速devil 指的是那些藏在代码里的小问题偶现的 500 错误、某一行诡异的空指针、配置文件里多出来的一个空格。这类问题往往不复杂但非常消耗排查时间。Picodevil 的核心思路是让 LLM 充当一个“代码排查副驾”它接收一段 issue 描述结合本地代码检索结果给出问题定位、可能原因和修复建议。很多人一提到 LLM 应用开发第一反应是“写一个聊天机器人”或者“调一个 API 完成 FAQ 问答”。但 Picodevil 想展示的是另一个方向LLM 不只是聊天它可以通过工具调用读取代码、搜索关键词、查看文件片段再基于真实上下文给出结论。这个项目不依赖复杂的 Web 前端也没有做炫酷的交互页面而是把重点放在“模型如何与开发环境协作”上。对于刚接触 LLM 工程化的开发者来说这样一个命令行工具反而更容易理解也更容易扩展。1.2 这个项目要解决什么问题日常开发中定位一个 bug 通常要经过“读日志、看报错、搜代码、翻文件、猜原因、再验证”的循环。这个过程很机械化但又不适合完全自动化因为很多判断依赖上下文。Picodevil 的思路是把机械部分交给工具把推理部分交给 LLM。它用 ripgrep 在仓库里搜索错误关键字用文件读取工具查看相关代码片段然后把结果返回给模型让模型自己判断下一步要查什么。这个项目同时也是一个很好的 LLM 工程学习样本。它包含了当前 LLM 应用开发里几个非常核心的模块提示词设计、Function Calling 工具调用、Agent 编排、上下文管理和安全边界控制。你可以把它看成一个小型 Agent 系统模型有权限调用工具工具返回结果后模型继续推理直到给出最终结论。理解这条链路之后再去看 LangChain、Spring AI、MCP 这些上层框架就会容易很多。1.3 适合哪些开发者阅读如果你是刚开始接触 LLM API并且想知道“除了对话还能做什么”本文可以给你一个完整的落地方案。如果你已经在使用 LangChain 或 Spring AI但不太清楚底层 tool calling 是怎么工作的本文也会帮你补上基础。前半部分偏概念讲解后半部分是可运行的 Python 代码建议你跟着章节顺序从环境准备开始一步步把项目跑起来。2. 环境准备与整体架构2.1 运行环境与依赖Picodevil 采用 Python 3 环境代码层面不依赖重量级框架。操作系统方面Windows、macOS、Linux 都可以运行只要终端能执行 Python 命令即可。为了隔离依赖建议创建虚拟环境。示例环境如下Python 3.10 或更高版本支持 Function Calling 的 LLM API或 OpenAI 兼容接口ripgrep用于代码关键词搜索Git用于演示仓库的管理依赖方面主要使用 OpenAI 官方 Python SDK 来调用模型。如果你使用的模型服务不是 OpenAI 官方而是 DeepSeek、通义千问、Ollama 等 OpenAI 兼容接口也可以直接替换 base_url。具体的依赖版本需要根据你安装时的最新稳定版调整本文不会把版本写死避免一段时间后文章失效。pip install openai python-dotenv在 Linux 或 macOS 上ripgrep 可以通过系统包管理器安装Windows 用户需要额外配置 PATH。如果不想安装 rg也可以把后面的工具函数改成grep -rn只是输出格式和性能会有所差异。2.2 LLM API 的选择在构建 LLM 应用时模型选择直接决定效果。Picodevil 需要对代码片段进行理解并支持工具调用所以建议选择上下文长度较长、function calling 能力稳定的模型。实际项目里可以先用一个小型模型跑通流程再换成更强的模型来做最终分析。为了不把服务商固定死代码里通过环境变量来管理 API Key、Base URL 和模型名称。这样你在本地用 OpenAI 官方服务在测试环境用公司内部模型只需改环境变量不需要改代码。下面是关键配置项的说明OPENAI_API_KEYAPI 密钥建议通过环境变量注入不要硬编码到代码里。OPENAI_BASE_URLAPI 服务地址使用 OpenAI 官方服务时可以不填。OPENAI_MODEL模型名称例如gpt-4o-mini也可以根据自身环境配置成其他支持工具调用的模型。PICODEVIL_MAX_STEPSAgent 最大执行步数防止模型无限循环。需要特别提醒的是不是所有模型都支持 Function Calling。如果你的模型不支持tools参数调用时会出现参数错误或空白返回遇到这种情况应该先确认模型是否具备工具调用能力。2.3 整体架构分层Picodevil 的分层并不复杂整体可以看作一个“输入 — 推理 — 工具 — 输出”的闭环。用户输入一个 issue 描述后程序会先组装 system prompt 和 user message然后调用 LLM。模型如果认为需要查看代码就会返回一个 tool_call程序解析这个调用并执行本地工具再把工具结果附加到消息列表里让模型继续推理。重复这个循环直到模型不再请求工具调用直接输出最终答案。可以用下面这个流程来理解issue 描述 ↓ 组装 messages ↓ 调用 LLM ↓ 是否请求工具 ├─ 是 → 执行工具(搜索代码/读取文件) → 把结果追加到消息列表 → 回到调用 LLM └─ 否 → 返回最终结论这种结构就是 Agent 编排的基本形态。很多人问“LLM 应用为什么需要编排框架”其实框架解决的问题就是这里的循环控制、工具管理、上下文维护和异常处理。Picodevil 先不引入框架直接用原生代码实现一套最小循环能让原理更透明。后续当工具越来越多、交互变得越来越复杂时再考虑引入 LangChain 或 Spring AI 这类上层工具。3. 核心环节拆解3.1 提示词设计提示词决定了模型的行为边界。Picodevil 的 system prompt 需要告诉模型三个信息它是谁、它的任务是什么、它应该遵守哪些规则。如果提示词写得太开放模型可能会自己编造代码路径如果写得太死板模型又无法灵活判断。我给 Picodevil 设计了一套简洁但足够强约束的 system prompt。内容包含以下几点角色定位代码审查与问题定位助手。工作原则先检索再下结论。输出要求必须包含文件路径和行号。信息不足时继续使用工具而不是猜测。最终输出格式问题定位、可能原因、修改思路、风险提示。代码片段是这样的SYSTEM_PROMPT 你是一个严谨的代码审查助手 Picodevil。 你的任务是根据用户提供的 issue 描述检索本地代码定位问题并给出修复建议。 规则 1. 必须先用工具查看代码信息不足时继续检索不要凭空猜测。 2. 涉及具体代码时必须引用文件和行号。 3. 如果若干次检索后仍无法定位请如实说明缺少哪些信息。 4. 最终输出格式 问题定位 可能原因 修改思路 风险提示 这段提示词看似简单但实际效果非常明显。它把模型从“自由闲聊模式”切换成了“问题定位模式”。如果你在自己的项目里复现建议先运行几轮观察模型哪一步容易跑偏再针对性调整规则。提示词不是一次写好的而是根据失败案例逐步迭代出来的。3.2 Function Calling 工具调用Function Calling 是让模型调用外部函数的能力。模型本身不执行代码它只是根据工具描述生成一个结构化调用请求。程序收到这个请求后在本地执行搜索或读取文件再把结果返回给模型。这里有一个容易误解的地方不是模型在执行函数而是模型在“申请”执行函数真正执行的是本地代码。在 OpenAI 风格的接口中工具定义是一个 JSON Schema 数组。每个工具需要包含名称、用途描述、参数结构和必填字段。模型会参考这些信息决定何时调用、传什么参数。下面是一个典型工具声明的格式TOOLS [ { type: function, function: { name: search_code, description: 在仓库中按关键词搜索代码返回文件和行号列表。, parameters: { type: object, properties: { keyword: { type: string, description: 要搜索的关键词例如 saveUser } }, required: [keyword] } } } ]这个声明的意义在于模型会知道存在一个叫search_code的工具也知道应该传入keyword参数。当模型返回的tool_calls不为空时程序逐个解析工具名称和参数调用对应的本地函数然后把结果包装成roletool的消息继续追加到对话中。整个交互过程比传统的“一问一答”多了一层状态管理但也正是这一步让 LLM 从“知识问答”走向“动手解决问题”。3.3 RAG 与代码检索RAG也就是检索增强生成核心思路是在模型生成答案前先从外部知识库中检索相关内容并把这些内容作为上下文注入提示词。Picodevil 的代码检索本质上就是一个轻量 RAG 场景。它不依赖向量数据库而是先用 ripgrep 做关键词匹配再用文件读取工具获取具体行。为什么要做检索而不是把整个仓库塞给模型因为模型上下文窗口有限而且代码仓库越大无关内容越多集中注意力反而越差。Picodevil 第一版采用“关键词定位 文件片段读取”的方式已经能覆盖很多 bug 定位场景。后续如果仓库非常大可以引入向量数据库把代码函数名、注释、错误信息等做 embedding用语义相似度召回再交给模型分析。这个升级方向是 RAG 在代码场景中的典型应用。在实现时要注意控制工具返回结果的大小。一次搜索可能返回几十个匹配结果如果全量返回会占用大量上下文。Picodavil 的做法是限制搜索条数和返回字符数比如只返回前 20 条匹配结果最多截断到 4000 字符。这样既保留关键信息又避免把上下文撑爆。3.4 Agent 编排有了工具调用还需要一个主循环来驱动模型。一次 LLM 调用不一定能直接完成任务模型可能需要“搜索关键词 A → 查看文件 B → 再搜索关键词 C”多步操作。这个循环就是 Agent 编排的最小实现。Picodevil 采用一个for循环来控制流程。每次循环都调用一次模型判断是否返回工具请求。如果有工具请求就执行工具并把结果追加到 messages如果没有工具请求就认为模型已经得到足够信息输出最终结论。为了避免死循环还需要设置最大步数。比如设置为 6 步意味着模型最多检索 6 次超过后强制终止并返回当前内容。这里的关键点是消息列表的拼接顺序。每次工具调用后需要把 assistant 的 tool_call 消息、工具返回消息都追加进去。很多初学者在实现时会漏掉 assistant 消息导致模型不知道自己是基于哪次请求调用工具的。正确的顺序是user 提问 → assistant 返回 tool_call → tool 返回结果 → assistant 继续推理。这个顺序也是 OpenAI 官方接口要求的。3.5 MCP 扩展当工具数量变多之后手动维护工具声明和调用逻辑会变得吃力。MCP也就是 Model Context Protocol是一套开放协议旨在解决 LLM 应用与外部工具连接标准化的问题。通过 MCP可以让 LLM 统一访问文件系统、数据库、GitHub、网页抓取等能力而不必为每个服务单独写适配层。Picodevil 目前没有强制依赖 MCP但代码里预留了扩展空间。如果要把 Picodevil 变成一个更完整的开发助手比如自动创建 GitHub Issue、读取网页文档、操作数据库就可以把工具下沉到 MCP Server 中让 Agent 通过 MCP 客户端统一连接。常见的连接方式是在一个配置文件中声明多个 MCP Server每个 Server 对应一种能力。例如 GitHub Server 负责读仓库、建 PR网页 Server 负责抓取文档内容。配置示例大致如下{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_PERSONAL_ACCESS_TOKEN: ${GITHUB_TOKEN} } } } }这个示例只用来展示连接思路具体字段要以你使用的 MCP SDK 版本为准。在生产环境中要把 Token 的权限范围控制到最小并注意审计工具的每一次调用。4. 完整实战实现一个最小可用的 Picodevil4.1 创建项目结构先创建一个名为picodevil的目录并在目录下建好包结构。为了让代码层次清晰我把工具逻辑、LLM 客户端、Agent 主循环和 CLI 入口拆到不同文件中。这样后续增加新工具时不需要改动主循环代码。picodevil/ ├── requirements.txt ├── .env.example ├── main.py └── picodevil/ ├── __init__.py ├── llm_client.py ├── tools.py └── agent.pymain.py是命令行入口picodevil/llm_client.py负责创建客户端和封装对话请求picodevil/tools.py里放所有工具函数和工具声明picodevil/agent.py里实现 Agent 主循环。如果后续要接入向量检索可以单独加一个retriever.py再用tools.py调用它隔离会更干净。4.2 配置环境变量与依赖在项目根目录创建requirements.txt内容如下openai python-dotenv然后创建.env.example文件方便其他人复制后改成自己的配置OPENAI_API_KEYsk-xxx OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-4o-mini如果你使用的是 Ollama 本地模型可以把OPENAI_BASE_URL改成 Ollama 提供的 OpenAI 兼容地址模型名改成本地已经拉取的模型名称。需要注意的是本地模型如果上下文较小Agent 多步调用时很容易超限建议选择参数较大的模型。4.3 编写工具模块在picodevil/tools.py中定义代码搜索和文件读取工具。这个模块里不涉及 LLM只负责本地文件系统的操作便于单独测试。# 文件路径picodevil/tools.py import os import subprocess def search_code(keyword, repo_path): 在仓库中搜索关键字返回匹配文件、行号和代码内容。 if not os.path.isdir(repo_path): return f目录不存在: {repo_path} cmd [rg, -n, --max-count, 20, keyword, repo_path] try: result subprocess.run( cmd, capture_outputTrue, textTrue, timeout10 ) except FileNotFoundError: return 未找到 rg 命令请安装 ripgrep或改用 grep 命令 output result.stdout.strip() if not output: return 未找到匹配内容 return output[:4000] def read_file(file_path, start_line, end_line): 读取指定文件的某一段代码。 if not os.path.isfile(file_path): return f文件不存在: {file_path} try: with open(file_path, r, encodingutf-8) as f: lines f.readlines() except Exception as e: return f读取文件失败: {e} total len(lines) start max(1, start_line) end min(total, end_line) content .join(lines[start - 1:end]) return f文件 {file_path} 第 {start} 到 {end} 行\n{content} TOOLS [ { type: function, function: { name: search_code, description: 在仓库中按关键词搜索代码返回匹配文件和行号。, parameters: { type: object, properties: { keyword: { type: string, description: 要搜索的关键词例如 saveUser } }, required: [keyword] } } }, { type: function, function: { name: read_file, description: 读取指定文件的指定行范围用于查看代码上下文。, parameters: { type: object, properties: { file_path: { type: string, description: 文件相对路径或绝对路径 }, start_line: { type: integer, description: 开始行号从 1 开始 }, end_line: { type: integer, description: 结束行号 } }, required: [file_path, start_line, end_line] } } } ] def dispatch_tool(name, arguments, repo_path): 根据工具名称调度本地函数。 if name search_code: return search_code(arguments.get(keyword), repo_path) if name read_file: return read_file( arguments.get(file_path), arguments.get(start_line, 1), arguments.get(end_line, 100) ) return 未知工具这里有两个设计细节值得注意。第一个是repo_path不直接让模型传入而是由程序在执行工具时注入避免模型随意访问其他目录第二个是工具返回结果做了截断因为模型上下文有限过长内容反而会稀释注意力。4.4 编写 LLM 客户端在picodevil/llm_client.py中创建客户端并封装一次对话调用。这里直接使用 OpenAI 风格接口同时通过读取环境变量支持多种兼容服务。# 文件路径picodevil/llm_client.py import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() API_KEY os.getenv(OPENAI_API_KEY) BASE_URL os.getenv(OPENAI_BASE_URL) or None MODEL os.getenv(OPENAI_MODEL, gpt-4o-mini) if not API_KEY: raise SystemExit(请先配置 OPENAI_API_KEY 环境变量) client OpenAI(api_keyAPI_KEY, base_urlBASE_URL) SYSTEM_PROMPT 你是一个严谨的代码审查助手 Picodevil。 你的任务是根据用户提供的 issue 描述检索本地代码定位问题并给出修复建议。 规则 1. 必须先用工具查看代码信息不足时继续检索不要凭空猜测。 2. 涉及具体代码时必须引用文件和行号。 3. 如果若干次检索后仍无法定位请如实说明缺少哪些信息。 4. 最终输出格式 问题定位 可能原因 修改思路 风险提示 def chat_once(messages, tools): 调用一次 LLM返回消息对象。 response client.chat.completions.create( modelMODEL, messagesmessages, toolstools, temperature0.2, ) return response.choices[0].messagetemperature0.2是为了让模型输出相对稳定。对于代码定位场景通常不希望模型发挥太多创造力而是希望它尽量严谨。如果你的模型接口不支持temperature或tools需要根据服务商的文档做兼容处理。4.5 编写 Agent 主循环在picodevil/agent.py中实现 Agent 循环。这个文件是项目的核心它负责拼装消息、调用模型、处理工具请求并控制最大步数。# 文件路径picodevil/agent.py import json from picodevil.llm_client import SYSTEM_PROMPT, chat_once from picodevil.tools import TOOLS, dispatch_tool def build_initial_messages(issue, repo_path): return [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f仓库路径{repo_path}\nIssue{issue}} ] def run_agent(issue, repo_path, max_steps6): messages build_initial_messages(issue, repo_path) for step in range(max_steps): assistant_message chat_once(messages, TOOLS) if not assistant_message.tool_calls: if assistant_message.content: return assistant_message.content return 模型没有返回有效内容请调整提示词或重试 assistant_record { role: assistant, content: assistant_message.content, tool_calls: assistant_message.tool_calls } messages.append(assistant_record) for tool_call in assistant_message.tool_calls: try: arguments json.loads(tool_call.function.arguments) except json.JSONDecodeError: arguments {} tool_result dispatch_tool( tool_call.function.name, arguments, repo_path ) messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result }) return 已达到最大执行步数请缩小问题范围或增加 max_steps这段代码最核心的是消息列表的追加顺序。模型返回tool_calls后必须先追加 assistant 消息再追加 tool 消息。如果顺序反了模型会无法理解某一次工具结果对应的是哪一次调用甚至直接报 400 错误。这个错误在本地完成最小闭环之前很容易遇到。4.6 命令行入口与运行验证最后写一个简单的命令行入口main.py让用户可以通过--repo指定代码仓库通过--issue传入问题描述。# 文件路径main.py import argparse from picodevil.agent import run_agent def main(): parser argparse.ArgumentParser(descriptionPicodevil: LLM 代码排查助手) parser.add_argument(--repo, default., help代码仓库路径) parser.add_argument(--issue, requiredTrue, helpissue 描述) parser.add_argument(--max-steps, typeint, default6, help最大执行步数) args parser.parse_args() result run_agent(args.issue, args.repo, args.max_steps) print(result) if __name__ __main__: main()运行前先复制环境变量文件并填入自己的 API Keycp .env.example .env然后执行python main.py --repo . --issue 用户点击保存按钮后接口报 500如果你在一个有对应代码仓库的环境中运行最终会看到类似下面的输出问题定位 疑似在 saveUser 方法中把 user_id 字段读取为空 文件路径为 src/services/user_service.py 第 42 行。 可能原因 HTTP 请求参数名与实体字段不一致前端传入 userId 但后端没有正确绑定该字段。 修改思路 检查 DTO 字段映射必要时添加 JsonProperty(userId)。 风险提示 修改后需要重新验证注册和编辑场景避免影响其他接口。这个输出只是一个示意实际结果取决于仓库内容和模型能力。如果你运行的仓库非常简单模型可能直接给出结论如果仓库复杂模型会先调用搜索工具再读取文件整个过程可能需要多轮。5. 常见问题与排查5.1 常见错误汇总在实际开发和复现过程中最常遇到的问题集中在接口兼容性、上下文超限和工具调度上。下面整理了一份问题排查表覆盖大多数情况。问题现象常见原因解决思路调用模型报 400 错误模型不支持 tools 参数或消息格式不符合接口要求确认模型支持 Function Calling检查 messages 列表顺序模型不回传 tool_calls直接给结论提示词约束不够或模型认为当前问题不需要继续检索在 system prompt 中强调“必须先检索”并给模型提供更具体的初始信息工具返回结果为空仓库路径不正确或关键词选取不合适检查--repo参数查看仓库目录是否存在尝试换更通用的关键词上下文超出限制多轮工具调用累积了大量代码片段截断工具返回内容或引入更精准的检索减少无关上下文Agent 陷入循环模型反复调用同一个工具且每次结果相似设置最大步数增加提示词中的退避规则限制同一工具调用次数搜索命令找不到 rg系统未安装 ripgrep或 PATH 未配置安装 ripgrep或者在工具函数中回退到grep -rn工具读取了不该读的文件LLM 根据路径猜测出敏感文件在工具层做路径白名单校验限制只能读取指定仓库内的文件5.2 排查清单当你遇到问题时建议按以下顺序排查而不是直接改代码。先看 API 请求日志确认 messages 是否完整、重复和顺序是否正确。然后看工具调度日志确认模型到底请求了哪些工具、参数是什么。再看工具返回内容确认搜索结果是否落到了预期文件。最后看模型输出确认它是否基于工具结果得出结论。这个过程很像调试一个普通接口服务只是输入端变成了 LLM输出端变成了工具调用链。为了更容易定位问题可以在每次工具调用后打印一行摘要例如“第 2 步调用 search_code参数 keywordsaveUser”。这样的日志在排查上下文超限和 Agent 循环时非常有用。6. 安全、权限与工程最佳实践6.1 工具权限边界LLM 工具调用带来的最大风险是权限失控。模型可能根据上下文请求执行写入操作、删除操作或读取敏感文件。如果工具层不设防一个看似无害的 issue 描述可能让模型改动生产代码甚至访问数据库。Picodevil 目前只提供搜索和读取工具相对安全但如果你在这个框架上扩展必须把权限边界放在首位。我的建议是遵循最小权限原则。只读工具可以放开写操作必须经过显式确认涉及删除、修改文件、执行命令的操作一律放到沙箱或测试环境生产环境的数据和密钥永远不注入到模型上下文。尤其要注意不要给模型提供“可以执行任意命令”的工具。你永远不会希望一个模型因为推理失误就在服务器上执行rm -rf或者调用生产数据库的删除接口。6.2 上下文长度与成本控制Agent 每调用一次工具都会把工具结果追加到 messages 中所以上下文长度会随着步数增长。如果工具返回的代码片段很大很快会触及上下文上限。控制上下文的核心方法是限制工具返回大小并在合适的时机结束循环。对于代码检索通常只需要返回匹配行和前后若干行不需要把整个文件塞给模型。成本控制也很重要。每轮工具调用都会产生一次 API 计费步数越多成本越高。建议在开发阶段把max_steps设小一点例如 4 步快速验证模型是否能收敛。等到逻辑稳定后再根据场景放宽步数。如果模型老是反复搜索同样的关键词可以考虑在提示词中增加“如果已经搜索过相同关键词请不要再重复调用”的约束。6.3 可观测性与日志LLM 应用很难调试因为模型输出存在不确定性。工程化的做法是把整个调用链记录下来。至少需要记录每次请求的 messages 结构、模型返回内容、工具名称、工具参数和工具结果。日志不仅用于排错还能帮助你评估模型的判断是否合理。推荐使用 JSON 结构化日志这样方便在日志平台中检索。每条日志包含 request_id、step、tool_name、tool_args、tool_result 等字段。有了完整链路一旦发现模型在某个场景下重复犯错就可以把这一段日志作为新的提示词优化样本回归测试后再上线。6.4 测试与回归LLM 应用的测试与传统代码测试不同不能只断言输出是否等于某个固定值。更实际的做法是准备一组测试用例每个用例标注期望行为和关键检查点。例如一个 issue 描述为“登录接口返回 401”关键检查点可以设置为“输出中包含文件路径”和“包含可能原因”。只要模型输出满足这些关键点就认为测试通过。Picodevil 的代码可以在不调用真实模型的情况下进行单元测试。比如直接测试dispatch_tool传入不同的参数断言结果是否符合预期。对于 Agent 循环只测消息拼接逻辑把chat_once替换为一个固定返回的 mock 函数。这样即使在离线环境下也能保证工具层和编排层不出现低级错误。7. 从 Picodevil 延伸的 LLM 开发学习路线Picodevil 只是一个起点但它把 LLM 应用开发里最重要的几块内容都串起来了。如果你接下来想继续深入可以从几个方向扩展。第一个方向是增强检索能力把关键词搜索升级为向量检索用 embedding 把函数名、注释、错误信息转化为向量再通过语义相似度召回相关代码。第二个方向是接入 MCP把 GitHub PR、数据库查询、网页抓取等能力统一管理起来让 Agent 能做更多自动化操作。第三个方向是完善工程化增加链路追踪、评估集、灰度发布和成本统计让 LLM 应用进入生产环境。在模型能力快速变化的时代最重要的不是掌握某一个框架而是理解 LLM 的工作方式提示词如何约束行为工具如何扩展能力上下文如何影响结果安全边界如何兜底。Picodevil 用最少的代码把这些原理都呈现了出来非常适合作为你动手改造的基础。建议先把最小闭环跑通再逐步增加工具和检索能力。当你在真实项目中看到 Agent 搜索代码、读取文件、最终给出定位结论的那一刻你对 LLM 应用开发的理解就真正从“调 API 对话”升级到了“构建自主系统”。