我做的项目是 Auto-Deployer，它本质上是一个 LLM 驱动的自动化部署工具。用户只需要提供 Git 仓库 URL，系统就可以自动分析代码仓库、识别技术栈、生成部署计划，并逐步完成部署，支持 SSH 远程部署 和 本地部署 两种模式。在这个基础上，我进一步把它从一个线性执行工具升级成了更工程化的 Agent 系统，重点做了三块增强：第一是基于 LangGraph 重构 Orchestrator 并做最小二开，第二是搭建了分阶段的 Prompt 体系，第三是补强了 知识库与检索模块，包括统一知识库、Hybrid Retrieval、Reranking 和 benchmark 评测流程。整个项目的核心目标，是把 LLM 从“会生成命令”提升成“能完成自动分析、执行、验证和失败恢复的部署 Agent”。
技术上，我主要围绕 Agent Runtime、Prompt Engineering 和 RAG 三个方向做实现。编排层使用 LangGraph 把原来的 RepoAnalyzer、Planner、Executor、Verifier/Repair 抽象成图式工作流节点，构建了 analyze、plan、select、execute、verify、recover 这样的部署流程；状态管理上设计了面向部署场景的 typed state schema，显式维护 plan version、step results、verification result、repair action、execution trace 和 checkpoint。Prompt 层我把提示词拆成 system、analysis、planning、execution、repair、interaction 几类，并要求执行阶段输出结构化 JSON action，避免模型自由发挥。知识模块则把 Repo Knowledge 和 Experience Knowledge 统一建库，在检索阶段组合 BM25 + 向量检索 + RRF 融合，再通过 cross-encoder reranker 做重排，同时用 benchmark 流程对不同检索配置做离线评测。
在 LangGraph 这部分，我没有直接照搬框架默认用法，而是做了一个最小二开版本，把部署流程拆成多个显式节点：先做仓库分析，再生成部署计划，然后按步骤选择和执行，执行后做结果验证，失败时进入恢复或重规划。为了让这个流程可控，我设计了部署专用的状态模型，里面会记录当前计划版本、当前步骤、步骤结果、验证结果、修复动作、执行轨迹和 checkpoint 路径；同时增加了 step budget 和 global budget 两层预算，避免 Agent 因为错误恢复反复陷入循环。Prompt 这部分，我重点做的是“分层推理”和“结构化动作输出”，正常场景用轻量推理降低 token 成本，遇到错误、超时、端口冲突等情况再切到深推理模式；执行输出被约束成 execute、ask_user、step_done、step_failed 这样的结构化 action，方便接入 orchestrator。知识增强部分则通过 corpus_builder 把 README、Dockerfile、package.json、requirements.txt、入口文件、配置文件以及历史部署经验统一组织成可检索文档块，并实现了 hybrid + rerank 的实验闭环。
这个项目里我遇到的问题主要集中在三类。第一类是 Agent 编排和执行问题，比如原始流程偏线性，失败恢复能力弱，简单 Python 脚本项目会被误判成 Web 服务，然后错误地去做端口健康检查。第二类是 Prompt 设计问题，一开始 few-shot 加进去之后效果并不稳定，后来发现不是单纯“提示词写得不好”，而是 few-shot 示例和当前 case 没有清楚隔离，出现了 contamination，示例里的技术栈特征会污染当前输入。第三类是 知识检索问题，原来的 old retriever 主要依赖历史经验库，无法覆盖当前仓库中的 repo-specific knowledge，导致 benchmark 基本打不到相关文档；同时实验过程中还遇到了本地模型加载不稳定、SentenceTransformer 本地目录不完整，以及 framework 过滤条件过严导致检索结果为空等问题。这些问题让我意识到，真正难的不是 happy path，而是失败恢复、上下文边界设计和检索链路的工程稳定性。
我的解决思路是把这些问题都工程化拆开处理。对于编排问题，我用 LangGraph 把部署任务改造成显式状态机，并加入 retry / replan / abort 的恢复分支，同时通过 failure classification 和 repair action 机制让系统先判断错误类型，再决定是重试、重规划还是中止；对于脚本型项目误判的问题，我增加了项目识别规则和计划修正逻辑，把简单 Python 项目的“启动服务 + 端口检查”替换成“执行脚本 + 输出验证”。对于 Prompt 问题，我把 prompt 从单一大 prompt 改成分阶段 prompt 体系，并把模型输出约束成结构化 JSON action；同时在 few-shot 部分显式区分 Examples 和 Current Case，减少上下文污染，并增加最小 prompt eval，用 framework accuracy、start command accuracy、invalid action rate 等指标比较不同 prompt variant。对于知识检索问题，我把 repo knowledge 和 experience knowledge 合并进统一知识库，改成 BM25 + 向量检索 + RRF 的 Hybrid Retrieval，再叠加 cross-encoder reranker，同时在评测中放宽过严的 framework filter，仅保留 repo 范围过滤，从而避免因为命名不一致把正确候选全部剔除。这一系列改动的核心思路是：不把 LLM 当成黑盒，而是通过编排、约束、检索和评测让整个系统变得可控。
最终，这个项目在两个层面都取得了比较明确的结果。第一，在 Agent Runtime / LangGraph 编排 层面，我已经在 Windows 本地环境完成了真实动态验收，成功跑通了简单 Python 项目的端到端部署流程，包括仓库准备、虚拟环境创建、脚本执行、结果验证和 checkpoint 落盘，证明这套系统已经具备“可编排、可恢复、可验证”的基本工程能力。第二，在 知识检索增强 层面，我完成了 benchmark 评测流程，在 6 个 benchmark repositories 上，Old Retriever 的 Hit@1、MRR 全为 0，而 Hybrid Retrieval 提升到了 Hit@1 = 0.5000、Hit@3 = 0.8333、MRR = 0.6667、nDCG@5 = 0.6757，显著优于原始 experience-only 检索方案；Hybrid + Rerank 在部分 case 上有帮助，但整体还没有稳定超过纯 Hybrid，因此当前阶段我会把 Hybrid Retrieval 作为默认方案，Reranker 作为可选增强模块。整体来看，这个项目让我把一个“会调用 LLM 的部署工具”进一步做成了一个更完整的 AI 应用 / Agent 工程系统。