agentic-rag-knowledge-graph 的 AI 编码规范实战CLAUDE.md 如何锚定项目上下文、约束代码边界并编排 MCP 工作流【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents本文以 CLAUDE.md 为核心解析 agentic-rag-knowledge-graph 项目为 AI 编码助手Claude Code制定的完整协作规范包括以 PLANNING.md/TASK.md 为上下文锚点的项目感知机制、500 行代码红线与模块化拆分、Pytest 三用例测试标准、Crawl4AI 与 Neon 两套 MCP 服务器的工作流编排以及风格约定与 AI 行为边界。读完你可以掌握一套可直接复用到自己 Python 项目中的AI 编码助手治理方法论并在仓库源码中找到每条规则的实际落地证据。CLAUDE.md 在项目中的定位agentic-rag-knowledge-graph 是一个将传统 RAG向量检索与知识图谱Neo4j Graphiti结合的 Pydantic AI Agent 系统用于分析大型科技公司的 AI 战略。其 README.md 在 Built with 部分明确写道项目使用了 Claude Code for the AI Coding Assistant (SeeCLAUDE.md,PLANNING.md, andTASK.md)。也就是说这个仓库是典型的AI 辅助构建项目——三份 Markdown 文档构成了人机协作的契约层文档角色CLAUDE.md 中的要求PLANNING.md架构蓝图系统架构、技术栈、设计原则、环境变量配置每次新会话开始必须首先阅读TASK.md任务台账按 Phase 0~7 组织的全部开发任务开始新任务前必须检查完成任务后必须立即打勾CLAUDE.md行为准则本身结构、测试、工具、风格、边界作为 AI 助手的系统提示词CLAUDE.md 全文约 72 行分为七个板块Project Awareness项目感知、Code Structure代码结构、Testing测试、MCP Server UsageMCP 工具、Task Completion任务闭环、Style Conventions风格约定、Documentation Explainability文档与可解释性外加AI Behavior RulesAI 行为边界。下面逐板块展开并用仓库源码印证每条规则。项目感知以 PLANNING.md 和 TASK.md 为双锚点CLAUDE.md 开篇的 Project Awareness Context 板块定下三条规则Always readPLANNING.md每次新会话开始时必须阅读以理解项目的架构、目标、风格和约束CheckTASK.md开始新任务前检查任务清单如果任务不在列表中补充进去并附简短描述和当天日期Use consistent naming conventions, file structure, and architecture patterns遵循 PLANNING.md 中描述的命名规范、文件结构和架构模式。这两份锚点文档在仓库中都有实据可依PLANNING.md 给出了完整的 ASCII 架构图API Layer → Agent Layer → Storage Layer 三层、/agent、/ingestion、/sql、/tests、/cli.py五大组件的职责划分、技术栈清单Python 3.11、Pydantic AI、FastAPI、PostgreSQLpgvector、Neo4jGraphiti以及全部环境变量定义DATABASE_URL、NEO4J_URI、LLM_PROVIDER、LLM_CHOICE、APP_PORT等。这正是AI 助手必须先读它的原因——架构约束和环境契约都集中在此而非散落在 README 里。TASK.md 是一条完整的任务流水账从 Phase 0MCP 集成到 Phase 7CLI 与 Agent 透明化每项任务用[x]打勾末尾还有 Project Status 总结58/58 测试通过、Production ready。这验证了完成任务后立即打勾的规则确实被严格执行过——Phase 4 的知识图谱构建、Phase 5 的全部测试项均处于完成状态。这种规划文档 任务台账 行为准则三件套本质上是把 AI 助手每轮对话都会丢失的会话上下文外化成了仓库内的持久化记忆。代码结构500 行红线、模块化与相对导入Code Structure Modularity 板块给出三条硬约束任何文件不得超过 500 行代码文件逼近该上限时必须重构拆分为多个模块或辅助文件按功能或职责把代码组织成清晰分离的模块使用清晰一致的导入包内优先使用相对导入。仓库源码可以逐条验证这些约定。以相对导入为例agent/agent.py 对同包模块全部采用from .prompts import SYSTEM_PROMPT、from .providers import get_llm_model的形式agent/api.py 则用from .agent import rag_agent, AgentDependencies、from .graph_utils import initialize_graph, close_graph, test_graph_connection等相对导入串联起整个 Agent 层ingestion/embedder.py 也遵循同一模式from .chunker import DocumentChunk。模块划分则与 PLANNING.md 的架构完全对齐agent/包内含agent.pyAgent 本体、tools.py检索工具、providers.pyLLM 提供商标杆、models.py数据模型等ingestion/包内含ingest.py、chunker.py、embedder.py、graph_builder.py各文件职责单一。一个值得注意的细节是用wc -l统计可发现agent/api.py664 行、ingestion/chunker.py517 行、agent/db_utils.py512 行实际超过了 500 行。从 CLAUDE.md 的措辞看该规则约束的是创建Never create新文件的行为即新增代码不允许突破红线存量文件在演进过程中超线属于规则执行中的常见松弛。读者在复现这套规范时可以把这条规则理解为新增文件硬性 ≤500 行存量文件超线时优先拆分。测试标准Pytest 三用例制度与镜像目录结构Testing Reliability 板块定义了项目最具体的质量要求任何新功能函数、类、路由等都必须创建 Pytest 单元测试每次更新逻辑后必须检查现有单元测试是否需要同步更新需要就更新测试放在/tests目录并镜像主应用的结构每个功能至少包含三类用例1 个预期用例expected use 1 个边界用例edge case 1 个失败用例failure case运行时必须激活venv_linux虚拟环境并使用python3执行命令。仓库的测试体系与上述要求高度吻合tests/ 目录下的tests/agent/含test_db_utils.py、test_models.py与tests/ingestion/含test_chunker.py分别镜像了agent/与ingestion/包的结构tests/conftest.py 在会话级 fixture 之外用os.environ.setdefault预先注入测试环境DATABASE_URL、NEO4J_URI、LLM_PROVIDER等并提供mock_database_pool这类 fixture用patchAsyncMock替换agent.db_utils.db_pool——这对应了 TASK.md Critical Fixes 中Update tests to mock all external dependencies (no real DB/API connections)的整改记录pytest.ini 则把质量底线工程化了addopts中开启--strict-markers、--strict-config、--verbose、--tbshort强制--covagent --covingestion并要求--cov-fail-under80覆盖率低于 80% 时测试失败markers定义了slow/integration/unit/asyncio四个标记asyncio_mode auto让异步测试无需逐个标注。这套配置意味着 CLAUDE.md 中必须写测试不是一句口号而是由 pytest 配置兜底不写测试或覆盖率不达标pytest命令本身就会失败。MCP 服务器工作流Crawl4AI 查文档、Neon 管数据库CLAUDE.md 的 MCP Server Usage 板块是全文最具操作性的部分规定了 AI 助手在开发过程中必须使用的两个 MCP 服务器及其调用顺序。Crawl4AI RAG MCP Server外部文档检索用途获取 Pydantic AI 的外部文档规则 1先调用get_available_sources查看已爬取的内容再决定检索什么规则 2寻找实现模式时使用search_code_examples。TASK.md 的 Phase 0 证实了这一工作流被实际执行过Use Crawl4AI RAG to get Pydantic AI documentation and examples 与 Query documentation for best practices and implementation patterns 两项均已勾选。这也解释了为什么代码中的 Pydantic AI 用法如RunContext、工具输入 Pydantic 模型、agent.iter()流式模式与其官方文档的模式高度一致——文档检索前置在流程里。Neon MCP Server数据库项目管理CLAUDE.md 给出了 Neon 服务器的完整工具集与标准工作流工具职责create_project创建新的 Neon 数据库项目run_sql执行 schema 与数据操作get_database_tables/describe_table_schema检查表与 schema项目 ID所有数据库操作都必须显式传入 project ID文档中定义的标准工作流为四步create_project— 创建新数据库项目run_sql schema SQL — 建表get_database_tables— 验证 schema 创建成功把返回的连接字符串用于应用配置。对照 TASK.md Phase 0 的 Neon Database Project Setup可以确认每一步都真实落地创建 Neon 项目、启用 pgvector 扩展、用run_sql创建documents/chunks/sessions/messages四张表、验证建表结果、获取连接字符串并更新环境配置、测试连通性——六项全部打勾。sql/schema.sql 中的 schema 与 PLANNING.md Database Schema 一节描述的四张表一一对应形成了MCP 执行 → SQL 文件留档 → 规划文档描述的三方一致。任务闭环TASK.md 的即时打勾与Discovered During Work机制Task Completion 板块只有两条但构成了完整的项目管理闭环任务完成后立即在TASK.md中标记不积压、不遗漏开发过程中发现的新子任务或 TODO必须追加到TASK.md的 Discovered During Work 区块。从 TASK.md 的实际内容看该机制运行良好不仅 Phase 0~7 的预定义任务逐项打勾还有一个专门的 Critical Fixes 区块记录了开发中发现的关键缺陷如Fix Pydantic AI tool decorators - Remove invaliddescriptionparameter、Fix agent streaming implementation usingagent.iter()pattern、Fix CORS to useallow_origins[*]、Graphiti 集成的六项修复每项都带[x]标记。这正是发现即记录规则的产物——问题不是消失在对话历史里而是沉淀为可追溯的任务项。风格约定Python 技术栈与 Google 风格 docstringStyle Conventions 板块规定了项目的技术选型与代码风格仓库源码均有对应实现主语言 Python遵循PEP8使用类型标注用black格式化数据校验使用 pydanticagent/models.py 直接from pydantic import BaseModel, Field, ConfigDict, field_validatoragent/providers.py 也基于pydantic_ai的类型体系构建多提供商抽象API 使用 FastAPIagent/api.py即 FastAPI 应用需要 ORM 时使用SQLAlchemy/SQLModel每个函数都必须写 docstring且指定了 Google 风格的模板def example(): Brief summary. Args: param1 (type): Description. Returns: type: Description. 仓库中的 tests/conftest.py 的 fixture如mock_database_pool就带着 Mock database pool for testing. 这样的 Google 风格简要描述。依赖方面requirements.txt 是一份完整的冻结依赖清单涵盖asyncpg、anthropic、cohere、boto3等为 black/ruff 等工具链版本提供了确定性基础——注意该文件是带 BOM 的 UTF-16 编码部分按 UTF-8 读取的工具会报错这是仓库的一个已知小坑。文档与可解释性README 同步与# Reason:注释Documentation Explainability 板块提出三条要求新增功能、依赖变更或安装步骤变化时必须更新README.md对非显而易见的代码加注释确保中级开发者能理解编写复杂逻辑时用内联# Reason:注释解释为什么而不仅仅是是什么。第一条在仓库中体现得最明显README.md 不仅覆盖安装、.env全量配置含 Ollama/OpenRouter/Gemini 三套提供商示例、ingestion 命令python -m ingestion.ingest及--clean、--chunk-size 800 --no-semantic --verbose变体、API/CLI 用法与 curl 测试样例还包含 Troubleshooting 章节与 TASK.md 的 Phase 7 文档更新任务相对应。而第三条# Reason:注释目前在整个仓库源码中尚无实例全文检索仅命中 CLAUDE.md 自身可以推断该约定是面向后续开发的预防性规则而非既有代码的既成事实。AI 行为边界四条硬性禁令CLAUDE.md 收尾的 AI Behavior Rules 是整个规范中最具防御性的一段针对的是大模型编码时的高频失效模式Never assume missing context. Ask questions if uncertain.—— 不确定就问禁止脑补项目背景Never hallucinate libraries or functions—— 只使用已知、已验证的 Python 包Always confirm file paths and module names exist—— 在代码或测试中引用某个模块前先确认它真实存在Never delete or overwrite existing code—— 除非用户明确指示或属于TASK.md中的正式任务。这四条禁令与前文的锚点机制形成闭环规则 1 由先读 PLANNING.md兜底规则 2 由Crawl4AI 查官方文档 冻结的 requirements.txt兜底规则 3 由模块化目录结构兜底规则 4 由 TASK.md 的任务授权机制兜底。TASK.md Critical Fixes 中对 Graphiti 的一系列修复如Remove similarity thresholds entirely from vector search、Fix PostgreSQL embedding storage format (JSON string format)都严格走任务清单登记印证了改动必须可追溯到任务的执行纪律。总结一套可复用的 AI 协作治理模式agentic-rag-knowledge-graph 的 CLAUDE.md 虽只有 72 行但构成了一套完整的AI 编码助手治理范式核心可提炼为五个层次层次规则仓库内验证点上下文每轮先读 PLANNING.md任务进 TASK.mdPLANNING.md 架构/环境变量与代码一致结构单文件 ≤500 行、按职责分模块、相对导入agent/ 与 ingestion/ 的包内from .xxx import质量每功能 ≥3 类用例、tests 镜像结构、强制覆盖率pytest.ini 的--cov-fail-under80、conftest 的 Mock 体系工具Crawl4AI 先查源再检索Neon 四步工作流必带 project IDTASK.md Phase 0 全部完成项边界不假设、不虚构、不越权删改代码Critical Fixes 全部经任务台账登记如果你在维护一个 PythonPydantic FastAPI pytest技术栈、且使用 AI 编码助手协作的项目可以直接照搬这套三文档结构行为准则 架构规划 任务台账把 CLAUDE.md 中500 行红线、三用例测试、MCP 工作流顺序、四条行为禁令作为最小可行规范集——它们每一条都能被 CI 或人工评审客观核验而不是依赖助手的自觉。【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 agentic-rag-knowledge-graph 的 AI 编码规范实战：CLAUDE.md 如何锚定项目上下文、约束代码边界并编排 MCP 工作流
agentic-rag-knowledge-graph 的 AI 编码规范实战CLAUDE.md 如何锚定项目上下文、约束代码边界并编排 MCP 工作流【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents本文以 CLAUDE.md 为核心解析 agentic-rag-knowledge-graph 项目为 AI 编码助手Claude Code制定的完整协作规范包括以 PLANNING.md/TASK.md 为上下文锚点的项目感知机制、500 行代码红线与模块化拆分、Pytest 三用例测试标准、Crawl4AI 与 Neon 两套 MCP 服务器的工作流编排以及风格约定与 AI 行为边界。读完你可以掌握一套可直接复用到自己 Python 项目中的AI 编码助手治理方法论并在仓库源码中找到每条规则的实际落地证据。CLAUDE.md 在项目中的定位agentic-rag-knowledge-graph 是一个将传统 RAG向量检索与知识图谱Neo4j Graphiti结合的 Pydantic AI Agent 系统用于分析大型科技公司的 AI 战略。其 README.md 在 Built with 部分明确写道项目使用了 Claude Code for the AI Coding Assistant (SeeCLAUDE.md,PLANNING.md, andTASK.md)。也就是说这个仓库是典型的AI 辅助构建项目——三份 Markdown 文档构成了人机协作的契约层文档角色CLAUDE.md 中的要求PLANNING.md架构蓝图系统架构、技术栈、设计原则、环境变量配置每次新会话开始必须首先阅读TASK.md任务台账按 Phase 0~7 组织的全部开发任务开始新任务前必须检查完成任务后必须立即打勾CLAUDE.md行为准则本身结构、测试、工具、风格、边界作为 AI 助手的系统提示词CLAUDE.md 全文约 72 行分为七个板块Project Awareness项目感知、Code Structure代码结构、Testing测试、MCP Server UsageMCP 工具、Task Completion任务闭环、Style Conventions风格约定、Documentation Explainability文档与可解释性外加AI Behavior RulesAI 行为边界。下面逐板块展开并用仓库源码印证每条规则。项目感知以 PLANNING.md 和 TASK.md 为双锚点CLAUDE.md 开篇的 Project Awareness Context 板块定下三条规则Always readPLANNING.md每次新会话开始时必须阅读以理解项目的架构、目标、风格和约束CheckTASK.md开始新任务前检查任务清单如果任务不在列表中补充进去并附简短描述和当天日期Use consistent naming conventions, file structure, and architecture patterns遵循 PLANNING.md 中描述的命名规范、文件结构和架构模式。这两份锚点文档在仓库中都有实据可依PLANNING.md 给出了完整的 ASCII 架构图API Layer → Agent Layer → Storage Layer 三层、/agent、/ingestion、/sql、/tests、/cli.py五大组件的职责划分、技术栈清单Python 3.11、Pydantic AI、FastAPI、PostgreSQLpgvector、Neo4jGraphiti以及全部环境变量定义DATABASE_URL、NEO4J_URI、LLM_PROVIDER、LLM_CHOICE、APP_PORT等。这正是AI 助手必须先读它的原因——架构约束和环境契约都集中在此而非散落在 README 里。TASK.md 是一条完整的任务流水账从 Phase 0MCP 集成到 Phase 7CLI 与 Agent 透明化每项任务用[x]打勾末尾还有 Project Status 总结58/58 测试通过、Production ready。这验证了完成任务后立即打勾的规则确实被严格执行过——Phase 4 的知识图谱构建、Phase 5 的全部测试项均处于完成状态。这种规划文档 任务台账 行为准则三件套本质上是把 AI 助手每轮对话都会丢失的会话上下文外化成了仓库内的持久化记忆。代码结构500 行红线、模块化与相对导入Code Structure Modularity 板块给出三条硬约束任何文件不得超过 500 行代码文件逼近该上限时必须重构拆分为多个模块或辅助文件按功能或职责把代码组织成清晰分离的模块使用清晰一致的导入包内优先使用相对导入。仓库源码可以逐条验证这些约定。以相对导入为例agent/agent.py 对同包模块全部采用from .prompts import SYSTEM_PROMPT、from .providers import get_llm_model的形式agent/api.py 则用from .agent import rag_agent, AgentDependencies、from .graph_utils import initialize_graph, close_graph, test_graph_connection等相对导入串联起整个 Agent 层ingestion/embedder.py 也遵循同一模式from .chunker import DocumentChunk。模块划分则与 PLANNING.md 的架构完全对齐agent/包内含agent.pyAgent 本体、tools.py检索工具、providers.pyLLM 提供商标杆、models.py数据模型等ingestion/包内含ingest.py、chunker.py、embedder.py、graph_builder.py各文件职责单一。一个值得注意的细节是用wc -l统计可发现agent/api.py664 行、ingestion/chunker.py517 行、agent/db_utils.py512 行实际超过了 500 行。从 CLAUDE.md 的措辞看该规则约束的是创建Never create新文件的行为即新增代码不允许突破红线存量文件在演进过程中超线属于规则执行中的常见松弛。读者在复现这套规范时可以把这条规则理解为新增文件硬性 ≤500 行存量文件超线时优先拆分。测试标准Pytest 三用例制度与镜像目录结构Testing Reliability 板块定义了项目最具体的质量要求任何新功能函数、类、路由等都必须创建 Pytest 单元测试每次更新逻辑后必须检查现有单元测试是否需要同步更新需要就更新测试放在/tests目录并镜像主应用的结构每个功能至少包含三类用例1 个预期用例expected use 1 个边界用例edge case 1 个失败用例failure case运行时必须激活venv_linux虚拟环境并使用python3执行命令。仓库的测试体系与上述要求高度吻合tests/ 目录下的tests/agent/含test_db_utils.py、test_models.py与tests/ingestion/含test_chunker.py分别镜像了agent/与ingestion/包的结构tests/conftest.py 在会话级 fixture 之外用os.environ.setdefault预先注入测试环境DATABASE_URL、NEO4J_URI、LLM_PROVIDER等并提供mock_database_pool这类 fixture用patchAsyncMock替换agent.db_utils.db_pool——这对应了 TASK.md Critical Fixes 中Update tests to mock all external dependencies (no real DB/API connections)的整改记录pytest.ini 则把质量底线工程化了addopts中开启--strict-markers、--strict-config、--verbose、--tbshort强制--covagent --covingestion并要求--cov-fail-under80覆盖率低于 80% 时测试失败markers定义了slow/integration/unit/asyncio四个标记asyncio_mode auto让异步测试无需逐个标注。这套配置意味着 CLAUDE.md 中必须写测试不是一句口号而是由 pytest 配置兜底不写测试或覆盖率不达标pytest命令本身就会失败。MCP 服务器工作流Crawl4AI 查文档、Neon 管数据库CLAUDE.md 的 MCP Server Usage 板块是全文最具操作性的部分规定了 AI 助手在开发过程中必须使用的两个 MCP 服务器及其调用顺序。Crawl4AI RAG MCP Server外部文档检索用途获取 Pydantic AI 的外部文档规则 1先调用get_available_sources查看已爬取的内容再决定检索什么规则 2寻找实现模式时使用search_code_examples。TASK.md 的 Phase 0 证实了这一工作流被实际执行过Use Crawl4AI RAG to get Pydantic AI documentation and examples 与 Query documentation for best practices and implementation patterns 两项均已勾选。这也解释了为什么代码中的 Pydantic AI 用法如RunContext、工具输入 Pydantic 模型、agent.iter()流式模式与其官方文档的模式高度一致——文档检索前置在流程里。Neon MCP Server数据库项目管理CLAUDE.md 给出了 Neon 服务器的完整工具集与标准工作流工具职责create_project创建新的 Neon 数据库项目run_sql执行 schema 与数据操作get_database_tables/describe_table_schema检查表与 schema项目 ID所有数据库操作都必须显式传入 project ID文档中定义的标准工作流为四步create_project— 创建新数据库项目run_sql schema SQL — 建表get_database_tables— 验证 schema 创建成功把返回的连接字符串用于应用配置。对照 TASK.md Phase 0 的 Neon Database Project Setup可以确认每一步都真实落地创建 Neon 项目、启用 pgvector 扩展、用run_sql创建documents/chunks/sessions/messages四张表、验证建表结果、获取连接字符串并更新环境配置、测试连通性——六项全部打勾。sql/schema.sql 中的 schema 与 PLANNING.md Database Schema 一节描述的四张表一一对应形成了MCP 执行 → SQL 文件留档 → 规划文档描述的三方一致。任务闭环TASK.md 的即时打勾与Discovered During Work机制Task Completion 板块只有两条但构成了完整的项目管理闭环任务完成后立即在TASK.md中标记不积压、不遗漏开发过程中发现的新子任务或 TODO必须追加到TASK.md的 Discovered During Work 区块。从 TASK.md 的实际内容看该机制运行良好不仅 Phase 0~7 的预定义任务逐项打勾还有一个专门的 Critical Fixes 区块记录了开发中发现的关键缺陷如Fix Pydantic AI tool decorators - Remove invaliddescriptionparameter、Fix agent streaming implementation usingagent.iter()pattern、Fix CORS to useallow_origins[*]、Graphiti 集成的六项修复每项都带[x]标记。这正是发现即记录规则的产物——问题不是消失在对话历史里而是沉淀为可追溯的任务项。风格约定Python 技术栈与 Google 风格 docstringStyle Conventions 板块规定了项目的技术选型与代码风格仓库源码均有对应实现主语言 Python遵循PEP8使用类型标注用black格式化数据校验使用 pydanticagent/models.py 直接from pydantic import BaseModel, Field, ConfigDict, field_validatoragent/providers.py 也基于pydantic_ai的类型体系构建多提供商抽象API 使用 FastAPIagent/api.py即 FastAPI 应用需要 ORM 时使用SQLAlchemy/SQLModel每个函数都必须写 docstring且指定了 Google 风格的模板def example(): Brief summary. Args: param1 (type): Description. Returns: type: Description. 仓库中的 tests/conftest.py 的 fixture如mock_database_pool就带着 Mock database pool for testing. 这样的 Google 风格简要描述。依赖方面requirements.txt 是一份完整的冻结依赖清单涵盖asyncpg、anthropic、cohere、boto3等为 black/ruff 等工具链版本提供了确定性基础——注意该文件是带 BOM 的 UTF-16 编码部分按 UTF-8 读取的工具会报错这是仓库的一个已知小坑。文档与可解释性README 同步与# Reason:注释Documentation Explainability 板块提出三条要求新增功能、依赖变更或安装步骤变化时必须更新README.md对非显而易见的代码加注释确保中级开发者能理解编写复杂逻辑时用内联# Reason:注释解释为什么而不仅仅是是什么。第一条在仓库中体现得最明显README.md 不仅覆盖安装、.env全量配置含 Ollama/OpenRouter/Gemini 三套提供商示例、ingestion 命令python -m ingestion.ingest及--clean、--chunk-size 800 --no-semantic --verbose变体、API/CLI 用法与 curl 测试样例还包含 Troubleshooting 章节与 TASK.md 的 Phase 7 文档更新任务相对应。而第三条# Reason:注释目前在整个仓库源码中尚无实例全文检索仅命中 CLAUDE.md 自身可以推断该约定是面向后续开发的预防性规则而非既有代码的既成事实。AI 行为边界四条硬性禁令CLAUDE.md 收尾的 AI Behavior Rules 是整个规范中最具防御性的一段针对的是大模型编码时的高频失效模式Never assume missing context. Ask questions if uncertain.—— 不确定就问禁止脑补项目背景Never hallucinate libraries or functions—— 只使用已知、已验证的 Python 包Always confirm file paths and module names exist—— 在代码或测试中引用某个模块前先确认它真实存在Never delete or overwrite existing code—— 除非用户明确指示或属于TASK.md中的正式任务。这四条禁令与前文的锚点机制形成闭环规则 1 由先读 PLANNING.md兜底规则 2 由Crawl4AI 查官方文档 冻结的 requirements.txt兜底规则 3 由模块化目录结构兜底规则 4 由 TASK.md 的任务授权机制兜底。TASK.md Critical Fixes 中对 Graphiti 的一系列修复如Remove similarity thresholds entirely from vector search、Fix PostgreSQL embedding storage format (JSON string format)都严格走任务清单登记印证了改动必须可追溯到任务的执行纪律。总结一套可复用的 AI 协作治理模式agentic-rag-knowledge-graph 的 CLAUDE.md 虽只有 72 行但构成了一套完整的AI 编码助手治理范式核心可提炼为五个层次层次规则仓库内验证点上下文每轮先读 PLANNING.md任务进 TASK.mdPLANNING.md 架构/环境变量与代码一致结构单文件 ≤500 行、按职责分模块、相对导入agent/ 与 ingestion/ 的包内from .xxx import质量每功能 ≥3 类用例、tests 镜像结构、强制覆盖率pytest.ini 的--cov-fail-under80、conftest 的 Mock 体系工具Crawl4AI 先查源再检索Neon 四步工作流必带 project IDTASK.md Phase 0 全部完成项边界不假设、不虚构、不越权删改代码Critical Fixes 全部经任务台账登记如果你在维护一个 PythonPydantic FastAPI pytest技术栈、且使用 AI 编码助手协作的项目可以直接照搬这套三文档结构行为准则 架构规划 任务台账把 CLAUDE.md 中500 行红线、三用例测试、MCP 工作流顺序、四条行为禁令作为最小可行规范集——它们每一条都能被 CI 或人工评审客观核验而不是依赖助手的自觉。【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考