1. 项目概述当你的代码助手拥有“结构化记忆”最近在折腾各种AI编程助手时我总感觉缺了点什么。无论是GitHub Copilot还是Cursor它们确实能帮我补全代码、回答一些基础问题但每次对话都像是和一个“金鱼脑”的同事合作——它记不住我们上一分钟讨论过的项目架构细节也搞不清我十分钟前刚定义的函数签名。每次新开一个会话都得从头解释一遍上下文效率大打折扣。这让我开始思考一个真正能“成长”的代码助手是不是应该像人类程序员一样拥有长期、结构化的记忆这正是“Your Code Agent Can Grow Alongside You with Structured Memory”这个项目标题所指向的核心。它不是一个具体的工具而是一种架构理念和实现路径。简单来说就是为你的AI编程助手Code Agent构建一个专属的、结构化的知识库Structured Memory让它能记住与你合作过程中的一切从项目规范、API文档、过往的bug修复记录到你个人的编码风格偏好。这个记忆不是杂乱无章的聊天记录而是经过组织、索引、易于检索的“第二大脑”。随着你们合作时间的增长这个助手会变得越来越懂你越来越懂你的项目最终从一个需要频繁指导的新手成长为能主动提出高质量建议、甚至预判你需求的资深搭档。这种“伴随式成长”的能力正是当前AI编程工具进化的关键分水岭。传统的代码补全工具是静态的、通用的而拥有结构化记忆的Code Agent则是动态的、个性化的。它的价值在于解决软件开发中那些高度依赖上下文和历史的痛点比如新成员接手一个老项目时的学习成本或者你自己隔了几个月后回头修改代码时的“失忆”时刻。一个拥有记忆的助手能将这些散落在各处的知识代码、注释、提交信息、文档、对话历史整合起来在你需要的时候精准呈现。2. 核心需求与架构设计解析2.1 为什么需要“结构化记忆”在深入技术细节前我们先得搞清楚痛点在哪。为什么普通的聊天记录保存不能满足需求我总结了几点核心需求上下文长度限制的终极解法当前大语言模型LLM的上下文窗口虽然越来越大从4K到128K甚至更多但对于一个长期开发、拥有数十万行代码和复杂历史的企业级项目来说依然是杯水车薪。你不可能每次都把整个代码库和历史对话塞给模型。结构化记忆的核心思想是“摘要”和“索引”只把最相关、最精华的部分送入上下文从而突破物理窗口的限制。知识的长效性与可进化性一次对话中解决的问题、总结的经验不应该在会话关闭后消失。例如你花了半小时向助手解释了项目中一个自定义的ORM框架的使用规范。在传统模式下下次遇到相关问题你又得重新解释。而结构化记忆会把这部分知识持久化存储并随着后续的验证和修正不断更新形成越来越准确的“项目知识图谱”。精准检索与关联推理记忆不是简单的文本堆积。当你在修改userService.js文件时助手应该能自动关联起记忆中存储的该服务依赖的数据库Schema、相关的API接口文档、历史上修改过该文件导致的Bug记录、以及团队约定的代码风格。这种跨文件、跨类型的关联能力是提升编码效率和质量的关键。个性化适配每个开发者都有自己的习惯。有人喜欢写详细的JSDoc有人偏爱简洁的代码有的团队用Redux有的用Zustand。结构化记忆可以学习并适应这些个人和团队的模式让生成的代码建议、重构意见更“合身”。基于这些需求一个典型的“结构化记忆”Code Agent架构会包含以下几个层次记忆采集层负责从各种源头获取原始数据。这包括代码库通过静态分析工具如Tree-sitter解析代码的抽象语法树AST提取函数、类、变量、导入关系等结构化信息。开发活动集成IDE操作流记录文件打开、编辑、搜索、调试断点等行为理解开发者的意图和关注点。对话历史不仅仅是保存问答文本而是对问答进行意图分类和关键信息提取例如识别出“解释登录逻辑”和“修复空指针异常”是两种不同类型的知识。外部知识主动爬取或链接项目相关的文档、技术规格说明书、API参考等。记忆处理与存储层这是核心。采集到的原始数据需要被“结构化”。向量化与嵌入使用文本嵌入模型如OpenAI的text-embedding-3-small或开源的BGE、voyage-2模型将文本片段代码块、文档段落、对话摘要转换为高维向量。这些向量捕获了语义信息使得语义相似的片段在向量空间中距离相近。结构化存储通常采用“向量数据库”如Pinecone, Weaviate, Qdrant或支持向量的关系型数据库如PostgreSQL的pgvector扩展来存储这些向量及其关联的元数据如来源文件、行号、类型、时间戳。知识图谱构建对于代码可以进一步构建轻量级的图结构存储“文件A包含类B类B继承自类C类C调用了函数D”这样的关系便于进行复杂的逻辑推理和影响分析。记忆检索与推理层当开发者提出一个问题或进行一个操作时Agent需要从记忆中召回相关信息。混合检索策略结合语义搜索基于向量相似度和关键词搜索基于BM25等传统算法。语义搜索擅长处理“用自然语言描述功能”的查询而关键词搜索对精准匹配函数名、变量名更有效。重排序初步检索出多个相关片段后使用一个更小、更快的模型或交叉编码器对结果进行重排序将最相关的结果排到最前面。上下文构建将检索到的、最相关的记忆片段与当前编辑的代码片段、最近的对话历史一起构建成一个结构化的提示Prompt发送给LLM如Claude 3, GPT-4进行最终的分析、推理和代码生成。应用层即开发者直接交互的界面可以是IDE插件VS Code, JetBrains、CLI工具或是Web应用。它负责触发检索、展示结果并将新的交互结果反馈给记忆存储层形成学习闭环。注意这个架构听起来复杂但开源社区已有不少探索。例如结合了上述思想的MemCoder或基于Claude Code Agent理念构建的工具都在尝试实现这一流程。关键在于不要试图一步到位构建一个完美的记忆系统而是从解决一个具体的、高频率的痛点开始迭代。2.2 关键组件选型考量搭建这样一个系统技术选型至关重要。以下是我在实验和评估中的一些心得嵌入模型的选择通用vs.代码专用通用嵌入模型如text-embedding-ada-002对自然语言和代码都有不错的表现。但专门的代码嵌入模型如Salesforce/codegen-350M-mono或microsoft/codebert-base在理解代码语法和结构上通常更胜一筹。如果你的记忆内容以代码为主优先考虑后者。维度与速度嵌入向量的维度越高通常表征能力越强但存储和计算成本也越高。对于代码记忆384维或768维的模型往往在精度和效率上取得较好平衡。需要实测对比召回率。实操心得不要盲目追求最先进的模型。先用一个中等规模、速度快的模型如BGE-M3或voyage-2跑通流程验证价值。优化检索策略如分块大小、检索数量对最终效果的影响往往比换一个顶级模型更大。向量数据库的选型托管服务 vs. 自托管Pinecone、Weaviate Cloud 等服务省心但可能有成本和数据隐私考量。自托管Qdrant或ChromaDB则更灵活可控。核心功能需求必须支持元数据过滤。这是实现“结构化”检索的关键。例如你可以查询“在backend/目录下与‘用户认证’相关的函数”这需要数据库能同时处理向量相似度和file_path LIKE ‘backend/%’这样的过滤条件。性能关注索引构建速度、查询延迟尤其是在过滤条件下的查询以及单机内存占用。对于个人或小团队项目ChromaDB的轻量易用是个不错的起点。LLM的选型代码能力Claude 3 Opus、GPT-4 Turbo、DeepSeek-Coder等在代码生成和理解上公认领先。开源模型中Codestral、CodeLlama系列也表现不俗。上下文长度与成本记忆系统的优势是减少对超长上下文的依赖因此可以选择性价比较高的模型如Claude 3 Haiku, GPT-3.5-Turbo来处理大多数检索增强生成RAG任务仅在需要深度推理时调用更强但更贵的模型。提示工程构建给LLM的最终提示Prompt是灵魂。它需要清晰指示LLM如何利用提供的“记忆”上下文。一个糟糕的提示会让再好的记忆检索也功亏一篑。3. 核心细节与实操要点3.1 记忆的“结构化”究竟如何实现“结构化”是区别于简单文本存储的核心。以下是一些具体的结构化策略代码的分块与元数据标注不要按固定长度分块简单按字符数或token数切割代码会破坏函数、类的完整性。应该基于AST以独立的函数、类、方法为最小单元进行分块。每个块附带丰富的元数据{ “content”: “async function getUserById(id) { ... }”, “metadata”: { “type”: “function”, “name”: “getUserById”, “file_path”: “src/services/userService.js”, “language”: “javascript”, “ast_info”: { “parameters”: [“id”], “return_type”: “PromiseUser” }, “last_modified”: “2024-05-20”, “author”: “developerA” } }对话历史的提炼与归档超越聊天记录每次有意义的对话结束后可以触发一个总结步骤。让一个LLM比如成本较低的Haiku分析这段对话提取出解决的问题例如“修复了在用户名为空时登录API崩溃的Bug”。学到的知识例如“项目中的validateInput函数不会处理null需要显式检查”。做出的决定例如“决定采用joi库替代手写验证逻辑”。将这些总结作为新的“记忆文档”存入向量库并链接到相关的代码块上。这样记忆就从“我们说过什么”变成了“我们学到了什么”。建立跨实体的关联利用代码的AST可以自动建立“调用”、“继承”、“包含”等关系。将这些关系以图数据库如Neo4j或简单的关系表形式存储。当检索到某个函数时可以顺藤摸瓜找到它的调用者、它调用的其他函数、它所属的类等形成一个相关的上下文网络一并提供给LLM。3.2 检索策略的优化技巧检索的质量直接决定了Agent回复的准确性。经过多次调试我总结了几个有效的优化点查询重写与扩展用户的原始查询可能很模糊比如“之前那个处理用户数据的函数”。直接用它做向量检索效果很差。可以在检索前用一个轻量级LLM对查询进行重写和扩展。例如扩展成“获取用户信息的函数可能叫getUser、fetchUser、queryUser在userService或api目录下用于读取用户数据”。也可以结合当前的编辑上下文自动生成查询。如果你刚输入// TODO: validate the email format系统可以自动生成查询“查找项目中现有的邮箱验证函数或正则表达式模式”。分层检索与融合第一层用扩展后的查询在向量库中进行语义检索获取一组候选片段。第二层同时用查询中的关键名词如“getUserById”在代码索引中进行精准的符号搜索。第三层如果元数据允许可以按文件路径、修改时间等进行过滤。最后将这三层的结果根据分数进行加权融合如语义相似度得分 * 0.7 关键词匹配得分 * 0.3得到最终排序列表。动态上下文窗口管理检索到的记忆片段可能很多但LLM的上下文窗口有限。需要设计一个优先级算法来动态选择哪些片段放入上下文。优先级可以考虑与当前编辑文件的关联度、记忆的新鲜度、历史被使用的有效次数等。实操心得一个简单的启发式规则很有效优先放入与当前文件在同一目录或直接导入关系的记忆其次是最近一周内被修改或引用过的记忆最后是全局通用的工具函数或配置说明。4. 实操构建一个简易个人代码记忆助手理论说了这么多我们来动手搭建一个最小可行产品MVP体验一下核心流程。我们将构建一个本地的、针对单个项目的代码记忆助手。4.1 环境准备与工具选型我们选择Python作为实现语言因为它有丰富的AI和数据处理库。嵌入模型选用sentence-transformers库中的all-MiniLM-L6-v2模型。它体积小80MB速度快对于代码文本的语义捕捉在实验级别足够用。生产环境可以考虑BGE或专门代码模型。向量数据库选用ChromaDB。它轻量、易用支持内存和持久化模式完全满足我们个人使用的需求且Python API非常友好。LLM为了流程完整我们使用Ollama本地运行codellama:7b模型。你也可以替换成任何你喜欢的API如OpenAI, Anthropic原理相通。代码解析使用tree-sitter和对应语言的语法库来解析代码实现基于AST的分块。首先安装必要的依赖pip install chromadb sentence-transformers tree-sitter requests ollama # 如果需要从源码安装tree-sitter语言库这里以Python为例 git clone https://github.com/tree-sitter/tree-sitter-python4.2 记忆库的初始化与代码索引第一步我们需要把目标项目的代码“记忆”下来。import os import chromadb from sentence_transformers import SentenceTransformer from tree_sitter import Language, Parser import json # 1. 初始化嵌入模型和ChromaDB客户端 embed_model SentenceTransformer(‘all-MiniLM-L6-v2’) chroma_client chromadb.PersistentClient(path“./code_memory_db”) collection chroma_client.get_or_create_collection(name“code_snippets”) # 2. 加载Tree-sitter Python语法 PYTHON_LANGUAGE Language(‘./tree-sitter-python.so’, ‘python’) # 需要先编译生成.so文件 parser Parser() parser.set_language(PYTHON_LANGUAGE) def extract_functions_from_file(file_path): “”“使用Tree-sitter解析Python文件提取函数定义。”“” with open(file_path, ‘r’, encoding‘utf-8’) as f: source_code f.read() tree parser.parse(bytes(source_code, ‘utf-8’)) root_node tree.root_node functions [] # 遍历AST查找函数定义节点 def _traverse(node): if node.type ‘function_definition’: # 获取函数名 name_node node.child_by_field_name(‘name’) func_name source_code[name_node.start_byte:name_node.end_byte] # 获取整个函数体文本 func_body source_code[node.start_byte:node.end_byte] functions.append({ “name”: func_name, “content”: func_body, “start_line”: node.start_point[0] 1, “end_line”: node.end_point[0] 1 }) for child in node.children: _traverse(child) _traverse(root_node) return functions def index_project(project_root): “”“遍历项目目录索引所有Python文件中的函数。”“” documents [] metadatas [] ids [] for root, dirs, files in os.walk(project_root): for file in files: if file.endswith(‘.py’): file_path os.path.join(root, file) rel_path os.path.relpath(file_path, project_root) functions extract_functions_from_file(file_path) for func in functions: # 将函数内容作为文档 doc_text f“Function {func[‘name’]} in {rel_path}:\n{func[‘content’]}” documents.append(doc_text) # 存储丰富的元数据便于过滤 metadatas.append({ “type”: “function”, “name”: func[‘name’], “file_path”: rel_path, “language”: “python”, “lines”: f“{func[‘start_line’]}-{func[‘end_line’]}” }) # 生成唯一ID例如文件路径_函数名_起始行 func_id f“{rel_path.replace(‘/’, ‘_’)}__{func[‘name’]}__{func[‘start_line’]}” ids.append(func_id) # 批量生成向量并存入ChromaDB if documents: embeddings embed_model.encode(documents).tolist() collection.add( embeddingsembeddings, documentsdocuments, metadatasmetadatas, idsids ) print(f“已索引 {len(documents)} 个函数片段。”) # 假设你的项目在 ./my_python_project index_project(“./my_python_project”)这段代码完成了核心的索引工作它遍历项目用Tree-sitter智能地提取每个函数作为一个独立的“记忆片段”并附上文件路径、函数名等元数据最后编码成向量存入数据库。4.3 实现记忆检索与问答Agent索引建立后我们就可以实现一个简单的问答循环了。def retrieve_relevant_memories(query, n_results5, filter_dictNone): “”“根据查询检索相关记忆片段。”“” # 将查询文本转换为向量 query_embedding embed_model.encode([query]).tolist()[0] # 调用ChromaDB查询 results collection.query( query_embeddings[query_embedding], n_resultsn_results, wherefilter_dict # 例如 {“file_path”: {“$contains”: “utils”}} ) # results 包含 ‘documents‘, ‘metadatas‘, ‘distances‘ 等 return results def ask_code_agent(question, context_code“”): “”“向代码助手提问它会结合记忆来回答。”“” # 1. 检索相关记忆 memories_result retrieve_relevant_memories(question, n_results3) retrieved_docs memories_result[‘documents’][0] if memories_result[‘documents’] else [] retrieved_meta memories_result[‘metadatas’][0] if memories_result[‘metadatas’] else [] # 2. 构建提示词 system_prompt “““你是一个智能代码助手拥有关于当前项目的记忆。请根据提供的‘项目记忆’和‘当前代码上下文’来回答问题。如果记忆中有相关信息请优先引用。如果记忆不足请基于你的编程知识回答。””” memory_context “\n\n--- 项目记忆 ---\n” for i, (doc, meta) in enumerate(zip(retrieved_docs, retrieved_meta)): memory_context f“[记忆片段 {i1}来自 {meta.get(‘file_path’, ‘未知’)}]\n{doc}\n\n” user_prompt f“““ 当前代码上下文 {context_code} 用户问题{question} {memory_context} 请回答上述问题并可以引用相关记忆片段。 ”“” # 3. 调用本地LLM (Ollama) import requests ollama_url “http://localhost:11434/api/generate” payload { “model”: “codellama:7b”, “prompt”: user_prompt, “system”: system_prompt, “stream”: False } try: response requests.post(ollama_url, jsonpayload) response.raise_for_status() answer response.json()[‘response’] return answer, retrieved_docs # 返回答案和引用的记忆 except Exception as e: return f“调用模型失败{e}”, [] # 示例使用 if __name__ “__main__”: # 假设我正在编辑一个文件有一段上下文代码 current_context “““ def process_user_data(user_id): # TODO: 需要先验证用户状态 user_info get_user_by_id(user_id) “““ question “项目中是怎么验证用户状态的有现成的函数吗” answer, used_memories ask_code_agent(question, current_context) print(“问题”, question) print(“\n助手回答”) print(answer) print(“\n--- 本次回答参考了以下记忆 ---”) for mem in used_memories: print(mem[:200] “...”) # 打印前200字符这个简单的Agent已经具备了核心能力它根据你的问题从之前构建的结构化记忆库中检索最相关的代码片段函数然后将这些片段作为上下文连同你的问题和当前代码一起发送给LLM从而得到一个基于项目实际情况的、精准的回答。5. 进阶优化与挑战应对上面的MVP展示了核心流程但要让它真正“好用”还需要解决一系列工程和算法上的挑战。5.1 记忆的更新、维护与失效代码项目是活的记忆库不能是静态的快照。增量更新需要监听文件系统的变化如使用watchdog库当文件被修改、新增或删除时触发对特定文件的重新解析和索引更新。对于修改的文件需要能定位到具体变化的函数更新或替换其对应的记忆向量而不是全量重建。记忆权重与衰减不是所有记忆都同等重要。一个很少被引用的工具函数其记忆权重应该低于一个被频繁修改的核心业务函数。可以设计一个衰减机制长时间未被检索或引用的记忆在检索排序中优先级逐渐降低甚至可以被归档。冲突与一致性当记忆中的信息与当前代码库的实际状态冲突时例如记忆说函数A接收两个参数但代码中已改为三个需要能检测并解决冲突。一种方法是在检索到记忆时快速检查其源文件是否已被修改通过哈希对比如果已修改则标记该记忆“已过期”并在回答中提示用户。5.2 提升复杂任务的理解与规划能力简单的问答只是开始。一个高级的Code Agent应该能处理更复杂的指令如“为这个模块添加单元测试”或“将这个函数重构为使用异步模式”。任务分解Agent需要将复杂指令分解成一系列可执行的子任务。例如“添加单元测试”可以分解为1. 理解模块功能2. 分析输入输出和边界条件3. 查找项目中类似的测试用例作为参考这里就用到了记忆检索4. 生成测试框架和具体用例5. 将生成的代码写入正确位置。记忆在规划中的作用在每一步记忆都能提供关键参考。在步骤3它能检索到项目的测试规范和范例在步骤4它能确保生成的测试代码风格与项目现有测试保持一致。实操心得实现复杂的任务规划目前仍然很有挑战性。一个务实的做法是预先定义好一系列“任务模板”比如“重构模板”、“测试生成模板”、“文档生成模板”。每个模板包含固定的步骤和每一步需要检索的记忆类型。当用户触发一个复杂指令时Agent先将其分类到某个模板然后按模板的步骤结合记忆库一步步执行。这比让LLM自由发挥要稳定得多。5.3 个性化与隐私安全考量记忆库可能包含敏感的代码逻辑甚至业务数据。本地化部署是底线所有核心组件——嵌入模型、向量数据库、LLM如果可能——都应优先考虑在本地或私有化环境中运行。像我们上面用ChromaDB和Ollama搭建的流程数据完全不出本地这是最基本的安全保障。记忆的访问控制在团队环境中可能需要更细粒度的控制。例如只允许Agent检索当前开发者有权限访问的模块的记忆。这需要在元数据中增加access_control标签并在检索时进行过滤。学习个人风格记忆系统可以刻意地学习你的代码风格。例如将你最终采纳的代码修改与Agent最初建议的对比作为正样本你拒绝的修改作为负样本微调一个轻量级的排序模型或偏好模型让Agent未来的建议越来越符合你的口味。6. 常见问题与排查技巧实录在实际搭建和使用的过程中我踩过不少坑。这里记录一些典型问题和解决思路。6.1 检索效果不佳找不到或找错记忆这是最常见的问题。症状是Agent的回答要么说“记忆中找不到”要么引用了完全不相关的代码。可能原因1分块策略不合理。排查检查你的分块单元是否太大如整个文件或太小如几行代码。太大的块包含太多噪声稀释了核心语义太小的块丢失了上下文。解决坚持以语法边界函数、类为分块单位。对于非常长的函数可以考虑按逻辑段落如注释分隔进一步细分但确保每个块语义相对完整。可能原因2查询与记忆的语义不匹配。排查将用户的原始查询和检索到的Top片段都打印出来人工判断相关性。你会发现很多时候是查询表述太模糊或太口语化。解决实施查询重写。在检索前用一个快速的LLM如GPT-3.5-Turbo或Claude Haiku将用户查询“翻译”成更贴近代码术语的搜索查询。例如将“那个搞用户的东西”重写为“user authentication, login, signup, User model”。可能原因3嵌入模型不擅长代码。排查用一些代码相关的标准查询测试不同嵌入模型的召回率。解决切换到专门的代码嵌入模型如microsoft/codebert-base。或者采用混合检索结合基于关键词的稀疏检索如BM25它能很好地匹配具体的标识符。可能原因4元数据过滤过严。排查如果你设置了where{“file_path”: {“$contains”: “src/”}}但有用的记忆在lib/目录下就会被过滤掉。解决在开发初期放宽过滤条件或者采用两阶段检索先全局语义检索再对结果用元数据过滤和重排序。6.2 Agent回答质量不稳定有时“胡言乱语”即使检索到了正确的记忆LLM给出的答案也可能跑偏。可能原因1提示词Prompt设计不佳。排查检查发送给LLM的完整提示词。记忆上下文是否被清晰地标注是否指示了LLM如何利用这些记忆解决优化提示词模板。使用明确的指令如“以下是来自项目代码库的相关参考片段请严格依据这些片段提供的信息来回答问题。如果参考片段中没有足够信息请直接说明。” 将记忆放在问题之前并用人眼清晰的标记如## 参考代码 ##分隔开。可能原因2记忆上下文过多或噪声大。排查检索返回了太多片段比如10个全部塞进了上下文导致LLM注意力分散。解决动态限制上下文长度。设定一个token上限优先选择与当前编辑文件最相关、最“新鲜”的记忆片段。或者使用LLM本身对检索结果进行摘要只把摘要放入上下文。可能原因3LLM本身的能力波动或知识过时。解决对于关键任务可以引入自我验证步骤。让Agent在生成代码或答案后再基于记忆库检查一遍是否有矛盾之处。或者对于代码生成任务要求它同时生成简单的单元测试来验证逻辑。6.3 系统性能与响应速度慢随着记忆库增长检索和推理延迟可能变得不可接受。可能原因1向量检索慢。解决索引优化确保向量数据库使用了合适的索引如HNSW。在ChromaDB中创建集合时可以指定hnsw:space等参数。量化考虑使用向量量化技术在损失少量精度的情况下大幅提升检索速度和减少存储。预过滤先利用元数据如文件路径、类型进行快速过滤缩小检索范围再进行昂贵的向量相似度计算。可能原因2LLM调用慢。解决模型分级简单的、基于记忆的问答使用小模型如7B参数复杂的、需要深度推理的任务才使用大模型。异步与流式将耗时的LLM调用异步化不让它阻塞主线程。对于代码生成采用流式输出让用户能边看边等。缓存对常见的、重复的查询及其结果进行缓存。例如对“项目如何启动”这种通用问题答案在短时间内不会变化可以直接缓存。构建一个能伴随你成长的Code Agent是一个持续迭代的过程。从今天这个简单的、只记忆函数代码的助手开始你可以逐步加入对文档、提交信息、错误日志的记忆再引入更复杂的检索策略和任务规划能力。最关键的是迈出第一步让它开始为你工作并在使用中不断调整和优化。你会发现当你的助手真正“记住”了项目的点点滴滴时那种协作的流畅感和效率的提升是任何一次性工具都无法比拟的。它不再是一个临时工而是一个逐渐熟悉你所有工作习惯和项目细节的长期伙伴。