AI 研发工程化实践：代码测绘、本地加速与自定义 Agent

当"用 AI 写代码"从尝鲜走向产研全流程，团队的瓶颈很快从"模型够不够强"转移到"工程体系能不能接住"。一个务实的观察是：AI 能力的重心在持续前移——从提示词工程、上下文工程，到 Harness 工程（给工具）、Loop 工程（自主闭环），再到 Graph 工程（多 Agent 编排）。每一层都是叠加而非取代：今天的工作台站在 Loop / Graph 层，但提示词与上下文仍是地基。

把这套逻辑落到研发场景，有三个常被低估、却决定落地质量的技术底座：代码测绘、本地加速、自定义 Agent。下面逐一展开。

一、代码测绘：先把仓库"画"清楚，再让 Agent 动手

问题
通用模型并不了解你的代码仓库——它的模块边界、依赖关系、历史约定、编码风格。直接让 Agent 改动，往往产出"语法正确但风格陌生"的代码，review 成本高、误伤风险大。

做法
在引入 Agent 之前，先对仓库做一次"测绘"——扫描目录结构、依赖图谱、模块边界与编码约定，生成一份可检索的"代码地图"，作为后续所有 Agent 调用的上下文基线。

价值
Agent 的改动更贴合仓库既有习惯，更少破坏隐性约定，也更易被人类 review。本质上，这是"上下文工程"在研发场景的第一块砖：没有对代码本身的、结构化的理解，再强的模型也是盲改。

二、本地加速：在合规边界内把检索做快、做近

痛点
在强监管行业，数据不能出域；公有云 API 既受限又持续计费。把代码 / 文档检索全部走云端，既不可行也不经济。

方案：把检索留在本地

• 本地优先 RAG 服务（以 MCP Server 形式直接接入工作台）：采用 AST 级语义分块 + 关键词 boost，能精准定位函数 / 类 / API；覆盖 50+ 编程语言及 PDF / DOCX / MD 等文档格式；纯本地、无 API Key、可离线运行。
• 增量索引框架：面向长周期 Agent 的"增量引擎"——代码发生变更时，只重算受影响的块（memoization），避免每次全量重建；同时落地向量化与知识图谱，作为可持续演进的数据底座。

收益
数据不出域、零调用费用、对国内网络环境友好。本地 RAG 相当于上下文工程的"就近取数"——让 Agent 在需要时即时拿到贴身上下文，而不是每次都向远端付费请求。私有 / 本地模型同样通过内部网络接入，按任务特性（短任务 / 长任务）分别调度。

三、自定义 Agent：把团队 know-how 固化成可复用资产

原则
不要把 Agent 当一次性对话工具，而要把"怎么问、怎么干"固化为资产。

• 在 L1 层，通过自定义专家、System Prompt、任务模板，把"怎么问"沉淀为可复用配置；
• 在业务侧，按岗位与场景自定义多个专家 Agent，把资深成员的领域 know-how 锁进角色设定，使新人也能以专家级质量产出；
• 关键是要"收得回"：将各部门自定义的专家 Agent、自动化任务打包归档进统一知识库，使经验不再停留在个人电脑，而是跨人、跨项目累积。

配套实践

• PR Agent（需求合规审查）：用 Story ID 将需求文档与代码分支串联，自动拉取需求、做代码 vs 需求的合规分析并产出 MR 评论。设计上采用四级降级（L1 完整分析 → L2 文档不合格由兜底转换 → L3 需求平台故障仅用 Story 描述 → L4 API 不可用则跳过需求检查、审查照常），确保任何外部依赖故障都不会阻塞代码审查。原则：稳定性优先、零习惯变更、轻量集成。
• 会话共享：AI 会话与上下文在团队间流转，一次排障 / 一次方案变成可检索、可复用的团队资产，同事可接力他人会话，减少"重新讲背景"的损耗。
• 业务提效路径：整理岗位职能与流程 → 明确输入输出产物 → 自定义专家 Agent → 对历史材料做"测绘"接入上下文 → 用连接器 / 自定义 MCP 打通上下游 → 在多角色共享空间协作。

小结

串起以上实践的是一张五层叠加的地图：提示词 → 上下文 → Harness → Loop → Graph。AI 落地的真门槛，不是模型本身，而是团队能否把"怎么干活"翻译成 AI 能执行、能被治理、能持续沉淀的工作流。代码测绘打基线、本地加速保合规、自定义 Agent 固化 know-how——三者共同构成 AI 研发工程化的底座。