Langfuse AGENTS.md 深度解读开源 LLM 可观测性平台的 AI Agent 协作规范与工程实践【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuseLangfuse 是一个开源的 LLM 工程平台用于 AI 应用的开发、监控、评估与调试。为了让 AI 编码 AgentClaude、Cursor、Codex 等在这个大型 TypeScript monorepo 中高效、安全、可验证地工作Langfuse 在仓库根部维护了一份被称为「Agent 宪法」的规范文件AGENTS.md根目录下是.agents/AGENTS.md的符号链接。本文以该文档为主体结合仓库实际源码与配置逐章拆解这份规范如何识别使用者身份、如何遵守验证纪律、如何交接上下文、如何理解 monorepo 结构、如何运行核心命令以及 Cursor Cloud 环境下独有的工作流。读完本文你将掌握在大型开源仓库中落地「多工具 Agent 协作」的完整方法论并能直接对照 Langfuse 仓库中的对应实现。一、背景为什么开源项目需要一份 Agent 规范Langfuse 仓库是一个横跨webNext.js 前端与 API、worker队列消费者与后台处理、packages/shared共享领域模型与数据访问、ee企业版扩展的大型 monorepo日常开发高度依赖多种 AI 工具链。AGENTS.md解决的核心矛盾是同一个仓库同时服务「外部贡献者」与「内部维护者」两类人群而 Agent 必须先搞清楚自己正在为谁工作才能决定可访问的信息边界与行为方式。注意根目录AGENTS.md是指向.agents/AGENTS.md的符号链接根目录CLAUDE.md又是指向AGENTS.md的兼容性符号链接。真正的「事实来源source of truth」位于 .agents/AGENTS.md这点在文档末尾的「Shared Agent Setup」一节有明确说明。.agents/目录被定位为与具体工具无关的中立事实来源指导内容只应放在AGENTS.md而.claude/、.codex/、.cursor/、.vscode/下的产物全部是生成出来的 shim不是源文件。二、身份识别先弄清楚你在为谁工作AGENTS.md开篇第一条准则就要求 Agent「永远不要默默猜测never guess silently」。身份判断是一个配置问题而非面试问题判定顺序如下读取~/.config/langfuse/me.md如果文件不存在则通过langfuse-onboarding技能的第 1 步确定身份在 Cursor Cloud 环境中身份来自cursor-cloud的run-infoowningUserName、owningUserEmail加上团队名册roster不能依赖gh api …permissions—— 因为 Cloud 的 GitHub token 是只读集成对维护者也报告push: false桌面端Desktop仍使用gh api user后读取.permissions.push。文档特别强调如果上述途径都无法确定使用者负责的领域应该只问一次并把答案写回~/.config/langfuse/me.md避免重复打扰。该文件「从不被覆盖」never overwritten因此人工修正可以在多次安装与 worktree 切换中存活 —— 这一行为在 .agents/README.md 的「Cursor Cloud」章节中有详细描述当LINEAR_API_KEY可用时仓库 postinstall 与 Cursor Cloud 启动都会验证 viewer 是否属于 Langfuse 团队并在不暴露密钥的前提下创建me.md。两类使用者的边界使用者获得的信息说明外部贡献者代码 CONTRIBUTING.md如何构建、检查要求、如何开 PR。不涉及 tracker、手册、工作周报——这些内容他们打不开提出来等于描述一扇锁着的门维护者全部以上 组织上下文助理Agent 应充当「组织记忆助理」而非「等待指令的代码补全引擎」对维护者文档给出五条具体行为要求回答「今天该做什么」不是凭记忆而是从 trackerLinear读取——他主导哪些项目、哪些需要在周一规划前更新、哪些已发布但未收尾对应linear-work-rhythm技能知道团队其他人在做什么同事每周发布项目更新。在设计某个界面之前先检查是否有同事近期动过它并主动提出——点名比报 ticket 更有用拿到链接就跑起来tracker ticket、PR、Slack permalink、截图——读它、弄清诉求、给出下一步不要反问该用哪个技能主动提示组织上到期的事项没人写的更新、挂在Merged却没有文档决策的 issue、静悄悄越过目标日期的项目——一行内提一次不搞例行报告主动提出实现方案不要等着被告知设计。另外团队工作手册content/handbook/**位于langfuse/langfuse-docs仓库的origin/main是必读材料当它与某个技能冲突时必须指出来——「两者之一必然有错」。三、工作准则How To Work这一节是 Agent 日常行为的操作守则核心可归纳为以下几个方面。3.1 上下文与委托策略只读取完成任务所需的最小本地上下文保持改动范围聚焦避免无关重构把探索性或噪声大的工作委托给子代理subagent大范围代码搜索、多文件调查、日志或测试输出梳理都应交由子代理执行避免中间工具输出污染主上下文。3.2 测试纪律按风险匹配验证而非按「改了东西」匹配文档对测试的态度相当鲜明只有能固定「没人注意就会回归」的行为时测试才配得上存在当唯一的断言只是在复述 diff某个间距值变成了新值、某个 label 显示了它显示的内容时这个测试「花掉一个文件却什么也没证明」——跳过它并用一句话说明为什么跳过当 bug 修复确实需要测试时先写最小的失败测试确认它在有缺陷的行为上确实失败再修改生产代码只有当另一个用例覆盖了不同的适配器、契约或执行路径时才增加第二个测试扩展最近接的既有测试套件不要为某个既有功能套件已拥有的行为另建孤立的常量测试。一个值得注意的细节如果 bug 依赖特定的数据形状先停下来问——pnpm run seed能否在本地预填该形状如果不能考虑扩展 seeder 场景见 packages/shared/scripts/seeder/AGENTS.md或者说明为什么 seed 无法表达它。预填本地测试数据一律使用 seed CLIpnpm run seed -- list可列出场景运行时会打印 UI 深链绝不使用临时脚本或裸 ClickHouse insert。3.3 预览环境与文档规范每个 PR 都会通过 GitHub Actions 自动构建一个一次性、全栈的预览环境pr-N.preview.langfuse.com——无需自行搭建使用langfuse-previews技能即可调试例如用kubectl读取预览的 web/worker 错误日志Markdown 中的文档截图避免在img上写死height优先使用 Markdown 图片或仅限宽度的 HTML以保持宽高比未经用户对具体规则与范围的明确批准不得新增或扩大 ESLint disable 注释或配置覆盖Shell 命令中的文件路径必须加引号或对路径密集的命令使用noglob避免 zsh 对动态 Next.js 路由的 glob 展开问题永远不要通过./node_modules/.bin/*调用 Node 安装的二进制一律通过pnpm运行。3.4 保密与外部可见内容绝不把内部 ticket idLFE-1234、LFINT-1234、CLI-Q226-12或 tracker URL 写进任何 OSS 读者会看到的地方代码注释、commit message、PR 标题与描述、changelog、面向用户的文档。ticket 前缀的分支名是唯一允许出现该标识符的地方唯一例外是.agents/skills/**这些文件是维护者指南其中的 id 是工程师可以追溯的出处provenance但 tracker URL 即便在这里也不允许出现代码注释只记录对未来读者有用的行为不记录当前改动背后的推理过程不引用 PR/评审历史「把 X 改成了 Y」「现在也处理」「按评审意见」「之前是」也不描述已不存在的代码绝不提交密钥或凭据.env*.example文件必须与必需的 env var 保持同步。3.5 人工交接与 PR 规范人工交接时假设读者不记得 ticket先用一句话 TL;DR每条消息优先只给一两个人工操作默认不倾倒长篇 agent 专属报告对产品/UI 改动给出预览 URLpr-N.preview.langfuse.com和精确的点击路径测试步骤包括复现数据的 seed 命令或 sandbox URLhttp://localhost:3000并把修复证明截图、短视频或前后对比发到 GitHub PR 上而不是只发在聊天里PR 应以「可评审」而非 draft 状态打开除非人类要求 draft当 Claude、Greptile 或 Codexchatgpt-codex-connector[bot]在你拥有的 PR 上留下评审意见时不要回复。保持线程打开直到应用修复并 resolve或确认可以跳过用直白的语言告诉人类并邀请其质疑这次跳过后 resolve。除非人类要求再来一轮否则不要再次发布claude review。四、上下文交接Context Handover文档指出任务中有两个「容易跳过、代价昂贵」的时刻其一触碰既有功能之前先重建它的历史。沿着 commits、承载它们的 PR 以及 head 分支名工作项标识符所在处回溯到工作项本身及此前任何 agent 上下文。具体命令在 .agents/skills/pr-stack-workflow/references/stack-commands.md 的Recover the context before you slice一节。已经被推翻过一次的决策不需要再次提出。其二请求评审或合并之前把推理留在工作项上——决策、反复、人类如何引导、踩过的坑。否则它活不过一次会话。在 PR 之前做而不是合并之后——「没有以后there is no later」。配套的实践、模板与工具是三个 Linear 相关技能.agents/skills/linear-context-handover/SKILL.md交接、.agents/skills/linear-planning/SKILL.md规划以及 .agents/skills/linear-agent-writes/SKILL.mdAgent 可以向 tracker 写什么、必须如何标记的唯一权威策略。文档要求「读这些技能而不是即兴发挥」如果环境无法访问 tracker必须在回复中说明并把本该写在工作项上的文本交还给人——永远不要默默跳过任一步骤因为静默的不合规看起来与合规一模一样。linear-agent-writes策略本身值得展开技能向 issue tracker 写入时不需要人工审批门禁护栏是「标记 三种受限写入形态」每种都要盖章并标注为 agent 书写。三种允许形态为仅当必须立即告知人类时评论编辑描述并追加清晰分隔的 agent 块绝不改写人类原文创建 ticket有父 ticket 的子 ticket 无需许可无父 ticket 需先经人类同意。分配、移动状态、关闭、估算、重新排优先级、删除、项目与新建 label 仍属于人类技能只能以建议形式提出。因为 tracker API 以配置它的人类身份认证未标记的 agent 写入与人类亲手输入无法区分所以技能必须在文本中标记作者身份而不只是贴 label。五、项目结构从 AGENTS.md 看 Langfuse MonorepoAGENTS.md用一张目录树概括了仓库布局这是理解整个工程的第一张地图langfuse/ |- web/ # Next.js app (UI tRPC public REST) |- worker/ # Queue consumers and background processing |- packages/shared/ # Shared domain, DB, queue contracts, repositories |- ee/ # Enterprise package consumed by web |- generated/ # Generated API clients (do not hand-edit) |- fern/ # API definition sources - scripts/ # Repo scripts5.1 依赖方向Dependency Direction规范明确规定了包之间的单向依赖这是保证模块边界不被破坏的硬约束web→langfuse/shared、langfuse/eeworker→langfuse/sharedlangfuse/ee→langfuse/sharedlangfuse/shared→不从web、worker或ee导入任何东西5.2 高信号共享入口文档为 Agent 指出了几个「高信号high-signal」的定位点便于快速找到核心契约队列载荷 schema 与队列名契约由 packages/shared/src/server/queues.ts 统一所有——这是 web/worker 之间消息传递的单一事实来源领域模型packages/shared/src/domain/observations.ts、packages/shared/src/domain/traces.ts、packages/shared/src/domain/scores.tsPostgres schemapackages/shared/prisma/schema.prismaClickHouse 迁移模板会分别渲染为 clustered 与 unclustered 两种安装形态packages/shared/clickhouse/migrations/canonical/ 下的*.sql架构原则沉淀在 .agents/ARCHITECTURE_PRINCIPLES.md。5.3 架构原则速览ARCHITECTURE_PRINCIPLES.md是 Agent 做架构决策时的判据核心思想包括以 observation 为基本分析单元trace 只是关联句柄偏好宽属性事件而非碎片化指标/日志/trace保留高基数上下文倾向不可变或追加式事件记录谨慎反规范化以消除热路径 join围绕列式访问模式设计存储与查询列表/仪表盘/聚合视图使用紧凑的查询优化表示大载荷只在聚焦详情视图取回API 契约要「规模感知」强制时间窗口、暴露字段选择、token 分页把成本与运维简洁性当作架构约束保留实时/近实时调试工作流。六、核心命令清单AGENTS.md给出的命令全部可在根目录 package.json 的 scripts 中验证monorepo 使用 pnpm turbo用途命令说明安装依赖pnpm install引擎要求 Node 24 / pnpm 12.3.1开发全部包pnpm run devturbo 并行启动仅开发 webpnpm run dev:web对应turbo run dev --filterweb仅开发 workerpnpm run dev:worker对应turbo run dev --filterworker全量 lintpnpm run lint每个包以--max-warnings 0运行 eslint全量 typecheckpnpm run typecheck/pnpm tc根级 typecheck 通过 turbodependsOn: ^build自动先构建 shared单文件测试见下文vitest 按文件名参数过滤构建检查pnpm run build:check输出到.next-check/完整构建pnpm run build含db:generate前置共享 Agent/worktree 引导bash scripts/agents/setup.sh幂等见 scripts/agents/setup.shWorktree 维护bash scripts/codex/maintenance.sh安装 Playwright Chromiumpnpm run playwright:install即pnpm --filter web exec playwright install chromium6.1 单文件测试的正确姿势vitest 以文件名参数过滤各包的调用方式不同# web 服务端测试 pnpm --filter web run test file # web 客户端测试 pnpm --filter web run test-client file # worker 测试 pnpm --filter worker run test file # shared 测试 pnpm --filter langfuse/shared run test file6.2 共享引导脚本的实际行为scripts/agents/setup.sh 展示了共享 Agent 引导的真实流程要求corepackNode.js 24 环境corepack enable用.env.dev.example/.env.test.example兜底创建.env/.env.testpnpm install --frozen-lockfileDocker 可用时构建repo/in-app-agent-sandbox-runtime的沙箱镜像安装 Playwright Chromium并在 worktree 中显式生成 Prisma client先pnpm --filtershared run db:generate再pnpm run db:generate避免被 turbo 缓存「满足」后 typecheck 用到旧分支产物。七、Cursor Cloud 专属指令Cursor Cloud 环境有一套与桌面端不同的约束AGENTS.md专门列出一节身份cursor-cloudrun-info的owningUserName、owningUserEmail再读团队名册。仓库 postinstall 与 Cloud 启动通常会先从LINEAR_API_KEY恢复~/.config/langfuse/me.md。忽略git configcursoragentcursor.com与 Cloudgh的.permissions.pushLinear 访问优先用已授权的 MCP否则用LINEAR_API_KEY或LINEAR_TOKEN/LINEAR_API_TOKEN做真实读取。交互式mcp_auth在 Cloud 中不可用。两者都不行时要求用户把LINEAR_API_KEY添加为 Cursor Cloud secret 并开启新的一次运行——本次运行看不到之后添加的 secret不要重复启动进程Cursor Cloud 通过 scripts/agents/start-cursor-cloud.sh 启动完整的源码构建栈不要在 3000 或 3030 端口再起第二个 web 或 worker 进程不要直接调用 Compose工作区.env包含面向宿主的localhost服务 URL不能用于插值容器服务配置必须使用该脚本改完 web/worker 生产代码后浏览器签核前要重新运行bash scripts/agents/start-cursor-cloud.shPR 规范本地验证后打开同仓库可评审 PR非 draft用合成数据测试生成的pr-N.preview.langfuse.com部署预览通常在欧洲/柏林时间周一至周五 08:00–24:00 运行开 PR 后主动打上 GitHubcursorlabel不要等人添加分支名必须用 Linear 的 git 分支名lfe-XXXX-short-title即使 Cursor Cloud 提示也不要创建cursor/前缀分支——仓库规范优先评审留言开 PR 后留一条简短的最后评论说明评审者应该质疑哪些点那些奇怪的、可疑的部分而不是 changelog对用户可见的工作把修复证明写进评论与 PR body。该评论只在 GitHub 会将其归于 Cursor 而非人类作者时才发布——Claude Code 等以用户身份评论的工具必须跳过参见cursor-agents-workflow。在 .agents/README.md 中可以看到 Cursor Cloud 更完整的机制启动脚本构建并等待 web、worker、PostgreSQL、ClickHouse、Redis、MinIO 六个服务播种合成演示项目并验证 web 与 worker 健康端点它会刻意阻止工作区.env与导出的应用变量参与 Compose 插值容器必须使用postgres、clickhouse、redis等 Compose 服务名seed 命令也收到显式本地连接 URL防止导出的 secret 把数据写入外部数据库还会处理嵌套 Cursor VM 中/var/run权限为0700导致docker.sock对ubuntu用户不可见的问题。八、本地数据检查Local Data Inspection功能测试与调试时规范允许直接检查本地数据库优先只读查询但创建前端测试状态仍必须走 seed CLI。开发 Docker Composedocker-compose.dev.yml在${HOST_IP:-127.0.0.1}上暴露以下客户端所有参数都有环境变量兜底默认值# Postgres PGPASSWORD${POSTGRES_PASSWORD:-postgres} psql \ -h ${HOST_IP:-127.0.0.1} \ -p ${POSTGRES_HOST_PORT:-5432} \ -U ${POSTGRES_USER:-postgres} \ -d ${POSTGRES_DB:-postgres} # ClickHouse clickhouse client \ --host ${HOST_IP:-127.0.0.1} \ --port ${CLICKHOUSE_NATIVE_PORT:-9000} \ --user ${CLICKHOUSE_USER:-clickhouse} \ --password ${CLICKHOUSE_PASSWORD:-clickhouse} \ --database default # Redis REDISCLI_AUTH${REDIS_AUTH:-myredissecret} \ redis-cli -h ${HOST_IP:-127.0.0.1} -p ${REDIS_HOST_PORT:-6379}连接失败时检查docker-compose.dev.yml中的本地覆盖变量并确认服务在运行。九、验证体系VerificationAGENTS.md的验证章节是全篇最有工程含量的一部分核心原则是**「用证据结束回合而不是用主张」**。9.1 按改动范围分级改动范围最低验证要求web/**pnpm run lint 针对性 web 测试worker/**pnpm run lint 针对性 worker 测试packages/shared/**非 schema 改动pnpm run lint 一次针对性 web 检查 一次针对性 worker 检查packages/shared/prisma/**或packages/shared/clickhouse/**pnpm run lint、pnpm run db:generate 针对性 web/worker 回归公共 API 契约web/src/pages/api/public/**、web/src/features/public-api/types/**、fern/apis/**pnpm run lint、针对性 server API 测试、Fern 更新/再生成、pnpm run openapi:check跨包重构pnpm run lint、pnpm run typecheck 受影响包的针对性测试9.2 客户端包健全性扫描CI 会对每个生产 web 构建运行pnpm run scan:client-bundle即node scripts/scan-client-bundle.mjs web/.next/static对应 scripts/scan-client-bundle.mjs扫描被 minifier 丢弃的绑定以及泄漏进浏览器 chunk 的 Node-only 全局变量——SWC dropped-binding 这类问题会携带仅在运行时出现的ReferenceError开发构建和类型检查都看不到。失败时脚本头部会解释规范修复方式。9.3 结束回合的输出纪律引用每个检查的摘要行例如Tasks: 8 successful, 8 totalturbo lint/typecheck或Tests 12 passed (12)vitest说明跳过了哪些检查及原因绝不把未验证的工作报为完成绝不以待办状态结束「通过的检查不等于运行过的检查」lint与typecheck是缓存型 turbo 任务worktree 共享同一缓存一次通过可能是另一分支结果的回放。Tasks: 1 successful, 1 total两种情况下打印得一模一样——引用Cached:那一行强制执行用pnpm exec turbo run lint --force--no-cache只停止写入不强制运行见turbo run lint --help所有参与 lint 的包web、worker、packages/shared、ee都以--max-warnings 0运行 eslint一个 warning 就会让分支失败langfuse/shared解析到其构建产物dist。根级pnpm run typecheck会先构建turbo.json 中typecheck.dependsOn包含^build但pnpm --filterweb run typecheck不会——切 worktree 换分支后先pnpm --filtershared run db:generate pnpm --filtershared run build否则 typecheck 报告的是上一分支的源码pnpm exec knip是 pipeline.yml 要求的检查但没有 package.json script很容易从不本地运行web/**、packages/shared/**、worker/**下未使用的文件与导出会导致失败没有检查会加载页面因此渲染改动只有被人看过才算验证——但那个人不必是你。真正不确定时可能 reflow 的布局、携带状态的流程、无法预测结果的交互才驱动浏览器改动小、视觉简单且信心高时说明改了什么、交出精确 URL让开发者扫一眼即可——主动提出不是甩锅静默跳过才是。没人在场且改动用户可见时必须自己检查。十、生成文件治理Generated Files规范明确禁止手工编辑生成或构建产物包括generated/*web/.next/*web/.next-check/**/dist/*packages/shared/prisma/generated/*公共 API 契约的改动必须更新fern/apis/**下的 Fern 源并重新生成输出绝不手改generated/**。这与仓库中 fern/ 目录API 定义源与web/public/generated/导出产物的分工一致——根目录 package.json 中的openapi:export脚本展示了从 Fern 导出到 OpenAPI 再后处理的完整链路。十一、共享 Agent 设置.agents 目录与 Skills 体系11.1 目录布局与 shim 生成机制.agents/README.md 给出了.agents/的布局AGENTS.md规范的共享根指令ARCHITECTURE_PRINCIPLES.md面向高规模可观测性的架构原则config.json共享引导与 MCP 配置用于生成各工具的 shimskills/与工具无关的、针对重复工作流的实现指南。根目录结构已由符号链接确认AGENTS.md - .agents/AGENTS.md、CLAUDE.md - AGENTS.md。scripts/agents/sync-agent-shims.mjs读取 .agents/config.json写出各产品所需的发现文件.claude/settings.json、.claude/skills/*、.cursor/mcp.json、.vscode/mcp.json、.mcp.json、.codex/config.toml等。发现文件以符号链接而非本地生成方式提交保证全新 clone 在pnpm install之前就有指导可用。改动后运行pnpm run agents:sync # 生成 shim pnpm run agents:check # 追加 --check-paths解析每个 AGENTS.md 引用的路径坏路径即失败路径校验被刻意排除在postinstall之外——在那里失败会破坏pnpm i及每个 CI 安装任务向上逃逸的引用../langfuse-docs/**只在可解析时才报告因为独立 clone 本就缺少兄弟检出。11.2 包局部指导窄化即效率规范要求把包局部指导放在拥有它的最窄AGENTS.md里只在需要时载入上下文。树中每个AGENTS.md在agents:sync时都会生成同级CLAUDE.md符号链接——当前包括web/、worker/、ee/、packages/shared/、packages/shared/scripts/seeder/。Claude 在打开某目录文件时会读取嵌套CLAUDE.mddot 目录在发现过程中被跳过避免 vendored skill bundle如web/.agents/skills/vercel-*/AGENTS.md变成目录级指令。新增任何一个AGENTS.md都必须提交其生成的 shim——否则 CI 失败。11.3 技能Skills设计与渐进式披露创建或编辑.agents/skills/**时必须使用 .agents/skills/skill-creator/SKILL.md。该技能定义了一套「渐进式披露progressive disclosure」的三级加载模型元数据namedescription——常驻上下文约 100 词是技能触发机制的唯一依据因此description必须同时写明「做什么」与「何时用」SKILL.md 正文——触发后才加载 5000 词 / 500 行上限捆绑资源scripts/、references/、assets/——按需加载脚本可执行而无需读入上下文。技能的目录结构约定为SKILL.md必备含 YAML frontmatter 可选的agents/openai.yamlUI 元数据scripts//references//assets/。仓库中.agents/skills/下已有 40 余个技能覆盖linear-*规划、交接、work-rhythm、agent-writes、langfuse-previews、langfuse-onboarding、pr-stack-workflow、seed-test-data、backend-dev-guidelines、clickhouse-best-practices、security-review等领域构成一套可复用的「领域专家」知识库。11.4 config.json共享配置中心.agents/config.json 包含四类数据shared跨工具默认值如setupScript: bash scripts/agents/setup.sh、devCommand: pnpm run dev、mcpServers项目 MCP 服务器含playwright、langfuse-docs、linear三个、以及claude/codex/cursor各自的生成设置输入。需要改动共享 MCP、引导命令或默认 dev 命令时编辑此文件再运行agents:sync与agents:check不要手改生成的 shim。注意.cursor/environment.json是唯一被提交进仓库的生成配置Cursor 必须先读它才能运行 install 脚本它同样由config.json生成、禁止手改。十二、总结一套可迁移的 Agent 治理范式Langfuse 的AGENTS.md表面上是给 AI Agent 的「使用说明」实质上是一份面向大规模开源 monorepo 的工程治理范本。它的价值可以归纳为四条可迁移原则身份先行Agent 的能力边界取决于服务对象用可推导的配置me.md、run-info而非猜测来确定身份避免「对锁着的门描述门内」验证与证据绑定按改动范围分级验证用检查摘要行结尾「通过的检查」必须能被证明真的运行过杜绝缓存回放式假绿上下文是公共品委托子代理、窄化包局部指导、渐进式披露技能、交接推理到工作项——所有机制都在为一个目标服务让有限的上下文窗口花在真正重要的事情上单一事实来源.agents/是真相CLAUDE.md、.cursor/、.codex/都是生成物契约队列、schema、领域模型有明确归属文件防止多源漂移。对于正在为自己的仓库建设 Agent 工作流的团队这份文档与 Langfuse 仓库中对应的落地实现.agents/AGENTS.md、.agents/config.json、.agents/skills/、scripts/agents/提供了一个开箱即用的参考蓝本——它展示了如何把「组织记忆」编码进文件系统让任何一个新启动的 Agent 实例都能立即继承团队的上下文、纪律与判断标准。【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考