Praxis MCP

Praxis（实践）

做的实践 --一种基于文件系统的代理开发方法。

来自希腊 *普拉索（Prasso）* --“去做，去行动，去实践。”

](https://github.com/luisfaxas/praxis) ](https://www.npmjs.com/package/praxis-mcp)   

*零依赖。只有文件夹、markdown和原生AI工具。*

______________________________________________________________________

在哲学中，亚里士多德创造了现代用法 *实践* 意味着 理论变成实践的过程。 它是知与行之间的桥梁——你有理论(*理论* /θεωρ943α）的一侧，以及 *实践* 另一方面，知识是通过深思熟虑的行动获得的。

这正是这种方法所做的。它弥合了人工智能代理之间的差距 *知道* （他们的训练、背景窗口、能力）以及他们 *做* （编写代码、研究、审计、报告）——通过结构化上下文、持久内存和可追溯的工作。

______________________________________________________________________

问题

人工智能代理功能强大，但健忘。每个新会话都从零开始。上下文窗口是一张白纸——昨天的决定、上周的架构选择、你选择PostgreSQL而不是MySQL的原因——除非有人把它写下来，否则都消失了。

大多数人通过写更长的提示来解决这个问题。他们粘贴项目上下文，重复指令，希望AI记住重要的事情。这适用于小任务。它对任何真实的东西都崩溃了。

快速驱动开发的问题：

• 短暂 --会话结束时，提示消失。没有审计追踪，没有历史记录。
• 非结构化 --指令分散在聊天消息中。没有什么是规范的。
• 无法追踪 --没有“完成”的概念。人工智能完成了任务吗？部分？谁检查？
• 单药 --提示假设一个AI。当多个代理协作时，没有路由、所有权和切换协议。
• 依赖人类记忆 --开发人员必须记住上次会话发生的事情并重新解释。人类和人工智能都有短期记忆的局限性。

Praxis通过文件系统解决了所有这些问题。没有数据库。没有SaaS平台。只有文件夹和标记。

______________________________________________________________________

工单：核心创新

实践中最重要的概念是 工单 --它来自一个意想不到的地方。

来源：建筑与制造业

在建筑中，a *工单* 是一份正式文件，授权并描述了一项特定的工作。它有一个范围、验收标准、指定的工人和“完成”的明确定义。当电工完成二楼的布线时，工单从“待处理”变为“完成”。有一份书面记录。有责任。关于所询问的内容或所传达的内容，没有任何歧义。

软件工程在票证和问题上采用了类似的概念——Jira、GitHub issues、Linear。但这些工具假设一个人类开发人员会阅读工单，在会话中携带上下文，并返回报告。

人工智能代理不是这样工作的。 他们每次都会重新开始。他们无法检查Jira。他们不记得昨天了。

人工智能代理的工作订单

Praxis将工单模式引入人工智能开发：

# Work Order: Implement Authentication Middleware

- **WO#:** 3
- **Date Created:** 2026-02-20
- **Status:** Pending
- **Assigned To:** Claude
- **Priority:** High

## Description
Add JWT-based authentication middleware to all /api routes.

## Acceptance Criteria
- [ ] Middleware validates JWT tokens on every /api/* route
- [ ] Invalid tokens return 401 with consistent error format
- [ ] Token refresh endpoint exists at /api/auth/refresh

此文件位于 dev/work-orders/。AI在会话开始时读取它。人工智能不符合验收标准。完成后，工单将移动到 executed/。没有歧义。

为什么工作订单会超过提示

||提示|工单| |--|---------|-------------| | 坚持 |与会话一起死亡|作为文件活着——永远生存| | 范围 |模糊、对话式|定义的接受标准| | 追踪 |“我问过这个吗？”|待定→ 已执行的管道| | 路由 |一个代理，一个提示|可路由到特定代理| | 审计跟踪 |无|文件就是线索| | 分解 |超级提示，永远成长|总体规划→ 增量WOs| | 多会话 |每次重新解释一切|AI读取WO时都是新鲜的——没有漂移|

工单对人工智能的发展就像集装箱对全球贸易一样，是一个任何代理都可以提取、处理和交付的标准化单元。

______________________________________________________________________

开发生命周期

Praxis将所有工作分为四个阶段：

graph LR
    R["Research
(gather)"] --> P["Planning
(decide)"]
    P --> E["Execution
(build)"]
    E --> Re["Reports
(communicate)"]

    style R fill:#667eea,stroke:#667eea,color:#fff
    style P fill:#764ba2,stroke:#764ba2,color:#fff
    style E fill:#9b59b6,stroke:#9b59b6,color:#fff
    style Re fill:#f093fb,stroke:#f093fb,color:#000

中的每个文件夹 dev/ 映射到这些阶段之一。当你打开一个Praxis项目时，你会立即知道所有东西在哪里以及为什么在那里。

横切关注点

研究：决策前先收集

研究是 第1阶段 --它向上游流入规划。一切都在 dev/research/ 存在以通知尚未做出的决定。

dev/research/
├── active/       # Research for current, open decisions
└── archive/      # Decision made — kept for reference

流程： 当你需要在PostgreSQL和MySQL之间做出选择，或者评估三个托管提供商，或者比较身份验证库时——调查就在 active/一旦做出决定并记录在 source_of_truth.md，研究转向 archive/。它永远不会被删除——它是你选择什么的收据。

常见研究类型： 定价比较、依赖性审计、技术评估、架构分析、安全咨询审查、竞争基准。

研究没有报告。 这种区别很重要。研究收集信息 *之前* 决定（上游）。报告传达结果 *之后* 工作已经完成（下游）。帮助您选择数据库的技术比较？研究。利益相关者的最新进展？报告。它们位于不同的文件夹中，因为它们服务于管道的不同阶段。

规划：建造前决定

规划是 第2阶段 --研究结果成为决策，决策成为可操作的计划。

dev/planning/
└── master-plan/
    ├── draft/      # Working plans (AI writes here)
    └── approved/   # Finalized plans (admin promotes)

流程： AI编写总体规划 draft/。管理员审核并推广 approved/人工智能从不直接向 approved/ --这个门确保了在工作开始之前，人类会审查每一个战略决策。

总体规划→ 工单分解： 总体规划捕获了整个项目路线图，分批次组织：

工作订单从总体规划中逐步分解，而不是一次分解。这可以防止作用域过载，并保持活动队列的焦点。

执行：构建可追溯性

执行是 第三阶段 --在那里，计划变成了现实。此阶段有两种工件类型：

工单 是主要的执行单元。它们在 工作订单部分 上述范围的任务，包括接受标准、分配的代理和待处理的任务→ 执行生命周期。

命令 处理一个特定的执行问题：当人工智能需要在服务器或工作站上运行多步shell命令时，它不能只是将它们粘贴到聊天中。相反：

dev/commands/
├── active/
│   └── 3_2026-02-20_SSL_SETUP/    # Topic subfolder with step-by-step commands
│       ├── 01_GENERATE_CERTS.md
│       └── 02_CONFIGURE_NGINX.md
└── executed/                        # Completed command sets

AI将命令写入 active/{topic}/ 并引用文档路径和步骤号： *“在中运行步骤1 dev/commands/active/3_2026-02-20_SSL_SETUP/01_GENERATE_CERTS.md."* 管理员审核并执行。已完成的集合移动到 executed/.

为什么选择文件而不是聊天？ 三个原因：（1）防止复杂的多行命令出现复制粘贴错误，（2）为系统上运行的每个命令创建审计跟踪，（3）允许管理员在执行前查看命令，这对破坏性操作尤为重要。

报告：传达结果

报告是 第四阶段 --管道的最后阶段。上游的一切（研究、规划、执行）都产生了结果。报告将这些结果传达给利益相关者。

dev/reports/
├── draft/
│   ├── html/       # Visual reports (interactive, styled)
│   └── written/    # Written analysis (markdown)
└── published/
    ├── html/       # Final HTML (admin promotes here)
    └── written/    # Final written (admin promotes here)

草案/公布的墙： AI写信给 draft/ 只有。管理员审查、编辑任何敏感信息（内部IP、凭据、PII），并向 published/AI从不读取或写入 published/这堵墙之所以存在，是因为已发布的报告会交给外部利益相关者——在离开项目之前，必须由人审查。

两种格式： HTML报告是可视化和交互式的——基准仪表板、进度电子邮件、风格化的演示文稿。书面报告是降价——技术分析、架构审查、决策文件。两者都遵循相同的草案→ 公布流量。

审核：跟踪质量

审计是 横切关注点 --它不属于单个管道阶段。审计可以在计划（发现）、执行（完成）或维护（漂移检测）期间进行。

dev/audit/
├── current/    # Active audit entries
└── legacy/     # Archived by admin

审核类型：

门楣(praxis-lint.sh)自动化一致性检查。发现和完成审计由三角形模式下的Manager代理执行，或由Solo模式下的任何代理执行。漂移报告通常是研究人员的责任——将文档中的声明与代码的实际功能进行比较。

______________________________________________________________________

上下文链

Praxis通过在每个会话中持续存在的三个活文档解决了人工智能健忘症：

graph LR
    SOT["source_of_truth.md
canonical rules"] --> CC["context_capsule.md
session handoff"]
    CC --> CP["checkpoint.md
milestones"]
    CP --> WO["Latest Work Order
current task"]

    style SOT fill:#667eea,stroke:#667eea,color:#fff
    style CC fill:#764ba2,stroke:#764ba2,color:#fff
    style CP fill:#9b59b6,stroke:#9b59b6,color:#fff
    style WO fill:#f093fb,stroke:#f093fb,color:#000

每个会话的读取顺序开始：

1. source_of_truth.md --规则是什么？
2. context_capsule.md --上次发生了什么事？
3. checkpoint.md --取得了什么成就？
4. 最新工单——我现在应该做什么？

每个会话结束时的写入顺序：

1. 更新 source_of_truth.md --有新的决定吗？
2. 更新 context_capsule.md --我做了什么？接下来是什么？
3. 更新 checkpoint.md --是否完成了任何里程碑？

这是Praxis的心跳。它将无状态的AI会话转化为一个持续的、可追溯的开发过程。

______________________________________________________________________

三角形图案

Praxis支持两种操作模式：

独奏模式（默认）

一个AI代理独立运行。工作订单是一个扁平的队列：

work-orders/
├── 1_2026-02-20_AUTH_MIDDLEWARE.md     (pending)
├── 2_2026-02-20_API_VALIDATION.md     (pending)
└── _executed/
    └── 0_2026-02-19_PROJECT_SETUP.md  (done)

三角形模式（多代理）

三个专门的人工智能代理协作，每个代理都有不同的角色：

graph TD
    M["Manager Agent
audits, plans, reviews, creates WOs"]
    I["Implementer Agent
implements code, deploys, tests"]
    R["Research Agent
deep research, SOT verification"]

    M -->|"work orders"| I
    M -->|"research WOs"| R
    I -->|"plans & results"| M
    R -->|"findings & reports"| M

    style M fill:#667eea,stroke:#667eea,color:#fff
    style I fill:#764ba2,stroke:#764ba2,color:#fff
    style R fill:#f093fb,stroke:#f093fb,color:#000

作业示例： Codex CLI担任经理，Claude Code担任实施者，Gemini CLI担任研究员。但任何能够读写文件的人工智能都可以扮演任何角色。

重要提示： 三角形是一种角色拓扑，而不是提供者锁定。

• 你可以用 三个不同的供应商 （例如Codex+Claude+Gemini）。
• 你可以用三角跑 三个并行会话中的同一提供者 （例如克劳德会话A/B/C，每个会话都有不同的角色）。
• 你可以用 混合私有/本地节点 （例如OpenCode或其他自托管代理），只要每个代理遵循相同的文件系统契约。

工作订单被发送到特定于代理的文件夹：

work-orders/
├── wo_implementer/
│   ├── 3_2026-02-20_AUTH_MIDDLEWARE.md
│   └── executed/
├── wo_manager/
│   └── executed/
└── wo_researcher/
    ├── 1_2026-02-20_JWT_LIBRARY_RESEARCH.md
    └── executed/

The Reflection Pattern — the core loop in Triangle mode (click to expand)

graph TD
    A["Manager creates WO"] --> B["Implementer writes plan"]
    B --> C["Manager reviews plan"]
    C -->|"Approved"| D["Implementer builds"]
    C -->|"Changes requested"| B
    D --> E["Manager audits result"]
    E -->|"Pass"| F["WO moves to executed/"]
    E -->|"Fail"| B

    style A fill:#667eea,stroke:#667eea,color:#fff
    style B fill:#764ba2,stroke:#764ba2,color:#fff
    style C fill:#667eea,stroke:#667eea,color:#fff
    style D fill:#764ba2,stroke:#764ba2,color:#fff
    style E fill:#667eea,stroke:#667eea,color:#fff
    style F fill:#2ecc71,stroke:#2ecc71,color:#fff

为什么这样做： 经理看到了全貌（发现审计+所有工作订单+所有计划）。实施者只看到其当前的工单。这种分离可以防止范围蔓延，并确保每个实施都与整体项目计划保持一致。

检测： 当存在多个提供程序初始化文件时，三角模式激活 dev/init/ （例如。， CODEX_INIT.md, GEMINI_INIT.md 旁边 CLAUDE_INIT.md).否则，Solo模式为默认模式。

超越三角形：可扩展拓扑

三角形是推荐的起始模式，因为它简单且可预测。Praxis本身并不局限于三个代理。

如果你的项目需要更多的并行性，你可以扩展到N-agent图（混合提供者、同一提供者并行会话和私有/自托管节点），同时保持相同的核心契约：

1. 角色所有权保持明确。
2. 工单路由保持确定性。
3. 验证和阶段关卡仍然有效。

实践统治 协调和上下文连续性 跨代理。它不会限制您使用哪个提供者或模型。

______________________________________________________________________

dev/文件夹

Full folder structure (click to expand)

dev/
├── source_of_truth.md              # Canonical rules and decisions
├── context_capsule.md              # Session handoff
├── checkpoint.md                   # Progress milestones
│
├── init/                           # Methodology reference docs
│   ├── PRAXIS_INIT.md           # Provider-agnostic init
│   ├── CLAUDE_INIT.md              # Claude Code init
│   ├── CODEX_INIT.md               # Codex manager init (Triangle)
│   └── GEMINI_INIT.md              # Gemini researcher init (Triangle)
│
├── research/                       # Stage 1: GATHER
│   ├── active/                     # Research for current decisions
│   └── archive/                    # Decisions made, kept for reference
│
├── planning/                       # Stage 2: DECIDE
│   └── master-plan/
│       ├── draft/                  # Working plans (AI writes here)
│       └── approved/               # Finalized plans (admin promotes)
│
├── work-orders/                    # Stage 3: EXECUTE
│   └── executed/                   # Completed work orders
│
├── commands/                       # Operator command delivery
│   ├── active/                     # Command sets in topic subfolders
│   └── executed/                   # Completed command sets
│
├── audit/                          # Quality + conformance trail
│   ├── current/                    # Active audit entries
│   └── legacy/                     # Archived entries
│
├── reports/                        # Stage 4: COMMUNICATE
│   ├── draft/
│   │   ├── html/                   # Draft HTML reports
│   │   └── written/                # Draft written reports
│   └── published/
│       ├── html/                   # Final HTML (admin promotes)
│       └── written/                # Final written (admin promotes)
│
├── design/                         # Design assets
│   ├── audit/screenshots/          # Visual captures
│   ├── language/                   # Design tokens + methodology docs
│   └── resources/                  # Icons, fonts, logos
│
├── private/                        # Sensitive docs (GITIGNORED)
│
└── archive/                        # Historical records
    └── {date}_{description}/       # Dated batches with manifests

______________________________________________________________________

提供商集成

实践是 提供者不可知。它可以与任何可以读写文件的AI助手配合使用。

提供者和角色是解耦的：

• 角色是可操作的(manager, implementer, researcher，或自定义角色集）。
• 提供者是实现选择（Claude、Codex、Gemini、OpenCode、私有/本地LLM等）。
• 如果保留角色边界，同一提供者可以通过单独的会话填充多个角色。

该方法不控制如何创建提供程序配置文件。每个提供者都按照自己的约定创建自己的配置：

两步初始化流程（重要）：

1. 原生初始化优先 --让AI在专用会话中创建自己的配置文件（例如，Claude创建 CLAUDE.md，Codex创建 AGENTS.md).AI充分关注其原生设置。
2. 实践初始化秒 --运行Praxis init（粘贴或引用 dev/init/*_INIT.md).实践 注入 将一个小的上下文切换块插入提供者的现有配置中——增强它，永远不要替换它。如果提供者配置不存在，Praxis将停止并要求您先运行步骤1。

这确保了AI知道在每个新会话中在哪里找到上下文链，而Praxis不会覆盖提供者的本地约定。

______________________________________________________________________

快速开始

选项A:CLI初始化（推荐）

npx praxis-mcp init                                     # starter tier, solo mode
npx praxis-mcp init --tier full --mode triangle          # full tier, multi-agent
npx praxis-mcp init --tier standard --path ./my-project  # custom path

这将创建 dev/ 文件夹结构、上下文文档， .praxis/praxis-lint.sh，以及（在三角形模式下）具有以下内容的代理文件夹 _executed/ 目录。一个命令，完全脚手架。

选项B：手动设置

启动器 （仅上下文链+工单）：

mkdir -p dev/work-orders/_executed

然后创建 dev/source_of_truth.md, dev/context_capsule.md，以及 dev/checkpoint.md.

满的 （完整的治理层）：

mkdir -p dev/{init,research/{active,archive},planning/master-plan/{draft,approved},work-orders/_executed,commands/{active,executed},audit/{current,legacy},reports/{draft/{html,written},published/{html,written}},design/{audit/screenshots,language,resources},archive,private}

配置您的提供商

从以下位置复制相关的init文件 dev/init/ 进入你的项目。克劳德代码：

cp dev/init/CLAUDE_INIT.md your-project/dev/init/

将提供者的init文件的内容粘贴到新会话中。AI将：

• 阅读你的代码库
• 填充上下文文档
• 将上下文切换注入到您的提供者配置中
• 执行架构审计（如果存在代码）
• 创建批次0工单（仅关键问题）

你现在正在运行Praxis。

______________________________________________________________________

操作规则

1. 非破坏性 --AI从来没有SSH到生产。仅限本地副本。
2. 自足 --每个项目都有自己的 dev/ 文件夹。按原样部署。
3. 没有工作区根文件 --所有输出都进入项目文件夹或dev/structure。
4. 草稿/已发布的墙 --AI写信给 draft/.Admin晋升为 published/.
5. 已执行意味着已完成 --项目将一直等待，直到完全完成。不要过早行动。
6. 命名约定 — {number}_{YYYY-MM-DD}_{DESCRIPTION}.{ext}编号0=自述文件。
7. 文件中的命令，而不是聊天 --AI从不在对话中粘贴多行命令。写信给 commands/active/ 并参考路径。
8. 每次会话都会更新上下文 --真相来源（决策）、总结（摘要）、检查点（里程碑）。
9. 开发中没有秘密/ -切勿将API密钥、密码、令牌或凭据存储在 dev/ 文件夹。使用 .env 机密文件（gitignored）。在晋升之前，对报告中的敏感数据进行修改。

______________________________________________________________________

WO车道系统

通道将工单组织到代理文件夹中的子项目范围中。它们是可选的——没有通道的项目与v1.2的工作方式相同。

车道命名

{nn}_{type}_{scope}

• 神经网络 --订购时使用两位数前缀（10、20、30…）
• 类型 --其中之一： delivery, program, lab, ops
• 范围 --Snake_case描述（例如。， academy, site_core)

例子： 10_delivery_academy, 70_program_methodology_rewrite, 80_lab_experimental_design

车道类型

集中完成

当车道上的WO完成时，它会移动到集中 _executed/ 目录：

wo_claude/
├── 10_delivery_academy/           # Active WOs
├── 20_delivery_site_core/         # Active WOs
└── _executed/
    ├── 10_delivery_academy/       # Completed WOs from this lane
    └── 20_delivery_site_core/     # Completed WOs from this lane

这可以保持活动队列的干净，同时保留通道组织的审计跟踪。

______________________________________________________________________

补丁工作订单

补丁WO扩展了已完成的父WO，以解决后续问题。他们使用 _P{NN} 后缀约定：

5_2026-02-22_ORIGINAL_TASK.md          # Parent (in _executed/)
5_2026-02-22_FIX_HEADER_BUG_P01.md     # Patch 1
5_2026-02-23_ADD_MOBILE_SUPPORT_P02.md  # Patch 2

所需元数据

每个补丁WO都包括父跟踪字段：

- **Parent WO:** 5
- **Patch:** P01
- **Sequence Key:** 5.01

序列键({parent}.{patch})允许按时间顺序在父级+补丁之间排序。

______________________________________________________________________

N/A标准

当WO范围确定后，验收标准变得不适用时，将其标记为N/A：

- [ ] ~~Criterion text~~ N/A — reason the criterion doesn't apply

复选框保持不变 [ ]，文本用删除线包裹(~~)，em破折号后面跟着一个原因。

护栏

______________________________________________________________________

安全和敏感数据

Praxis旨在驻留在Git存储库中。这些规则可防止意外接触：

• 永远不要泄露秘密。 API密钥、密码、令牌和凭据属于 .env 文件，不在 dev/ 文件。
• 出版前进行修改。 报告在 draft/ 可能会引用内部IP、用户名或基础设施详细信息。在晋升之前进行补救 published/.
• 这 .gitignore 事项。 Praxis船只配备 .gitignore 这排除了常见的秘密模式。为您的项目扩展它。
• 敏感文物进入 dev/private/. 将其用于合同、凭证引用、带有PII的内部注释，或应存在于项目上下文中但从不存在于版本控制中的任何文档。添加 dev/private/ 到你的项目 .gitignore.按路径从真相来源引用私人文档（例如，“凭据 dev/private/server_creds.md").
• 命令文件值得额外审查。 命令文档 commands/active/ 可能包含连接字符串、服务器地址或凭据。在提交git之前进行审查。

有关MCP服务器安全模型（路径安全、并发、已知风险），请参阅 安全.md.

______________________________________________________________________

采用级别

你不必在第一天就使用所有东西。从小处着手，随着复杂性的增加而增加结构。

初学者——上下文链+工单

最小可行实践。只有3个文件和1个文件夹：

dev/
├── source_of_truth.md
├── context_capsule.md
├── checkpoint.md
└── work-orders/
    └── executed/

最适合： 独立开发者，小项目，快速实验。您可以以接近零的开销获得会话连续性和任务跟踪。

标准——增加研究与规划管道

没有审计/报告基础架构的完整开发生命周期：

dev/
├── source_of_truth.md, context_capsule.md, checkpoint.md
├── research/{active, archive}/
├── planning/master-plan/{draft, approved}/
├── work-orders/executed/
└── commands/{active, executed}/

最适合： 中型项目、多期工作、建设前需要规划的项目。

完整治理层

一切。审计跟踪、报告管道、设计资产、档案：

dev/
├── (all Standard folders)
├── audit/{current, legacy}/
├── reports/draft/{html, written}/, published/{html, written}/
├── design/{audit/screenshots, language, resources}/
└── archive/

最适合： 多代理工作流、企业项目、长时间运行的构建、具有利益相关者报告的项目。

______________________________________________________________________

文件命名约定

所有文件如下： {number}_{YYYY-MM-DD}_{DESCRIPTION}.{ext}

• 数字 --顺序，按时间顺序（0，1，2，…）
• 日期 --ISO格式的创建日期
• 描述 --大写，下划线分隔
• 数字0 保留用于README和示例

1_2026-02-20_AUTH_MIDDLEWARE.md
2_2026-02-20_API_VALIDATION.md
0_2026-02-20_README.md

______________________________________________________________________

验证（praxis-lint）

Praxis包括一个自动验证工具，用于检查您的 dev/ 文件夹符合方法论。它将Praxis从基于约定（您自愿遵守的规则）转变为强制约定（自动验证的规则）。

快速开始

bash .praxis/praxis-lint.sh              # Lint current project
bash .praxis/praxis-lint.sh --fix        # Auto-create missing directories
bash .praxis/praxis-lint.sh --json       # JSON output for hooks/CI
bash .praxis/praxis-lint.sh --strict     # Warnings become failures
bash .praxis/praxis-lint.sh --help       # Full usage information

检查内容（7个类别，50个检查）

Session Lifecycle — start, end, and detect (click to expand)

Context Chain — read, update capsule, update checkpoint (click to expand)

Work Orders — list, read, create, complete, patch (click to expand)

Validation — lint (click to expand)

Scaffolding — scaffold (click to expand)

它在实践中是如何工作的

MCP服务器使用 stdio传输 --这是一个使用JSON-RPC 2.0协议通过stdin/stdout进行通信的过程。你在AI工具的配置文件中注册它，工具就会自动出现。AI将它们称为原生函数。

你不用手动调用这些工具。 AI给他们打电话。当Claude Code启动会话并看到Praxis MCP工具可用时，它会调用 session_start 而不是手动读取文件。当它创建工单时，它会调用 create_work_order 而不是构建markdown。这些工具由AI自动调用，作为其正常工作流程的一部分。

服务器是 无状态 --调用之间没有内存状态。每个工具都从文件系统读取并写入文件系统。文件系统就是状态。这符合Praxis的核心理念：一切都是文件，一切都是透明的，一切都可以审计。

设置

从npm安装：

npm install praxis-mcp

就是这样。服务器已经可以使用了。

注册克劳德代码 (.mcp.json 在您的项目根目录中）：

{
  "mcpServers": {
    "praxis": {
      "command": "npx",
      "args": ["praxis-mcp"],
      "env": { "PRAXIS_PROJECT_DIR": "/path/to/your/project" }
    }
  }
}

注册Codex CLI (~/.codex/config.toml):

[mcp_servers.praxis]
command = "npx"
args = ["praxis-mcp"]

[mcp_servers.praxis.env]
PRAXIS_PROJECT_DIR = "/path/to/your/project"

从源代码构建 （仅限贡献者）：

git clone https://github.com/LuisFaxas/praxis.git
cd praxis/praxis-mcp && npm install && npm run build

工具显示为 mcp__praxis__session_start, mcp__praxis__create_work_order, mcp__praxis__lint等等。这 PRAXIS_PROJECT_DIR 环境变量告诉服务器要在哪个项目上操作-工具默认为该路径，因此AI不必在每次调用时都传递该路径。

建筑

praxis-mcp/
├── src/
│   ├── index.ts              # CLI routing + McpServer + stdio transport
│   ├── cli-init.ts           # npx praxis-mcp init command
│   ├── tools/                # One file per category
│   │   ├── session.ts        # session_start, session_end, detect_project
│   │   ├── context.ts        # read_context, update_capsule, update_checkpoint
│   │   ├── work-orders.ts    # list, read, create, complete, create_patch
│   │   ├── lint.ts           # Spawns praxis-lint.sh
│   │   └── scaffold.ts       # TypeScript mkdir by tier/mode/lanes
│   └── lib/                  # Shared utilities
│       ├── constants.ts      # Tier maps, WO/patch templates, lane/naming regex
│       ├── fs-helpers.ts     # Safe file I/O, lane discovery, executed resolution
│       ├── detection.ts      # Tier, mode, and provider detection
│       ├── parsers.ts        # WO (with N/A + patch), capsule, checkpoint, SOT
│       └── naming.ts         # Auto-numbering, patch suffixes, filename formatting
├── templates/                # Bundled for CLI init
│   └── praxis-lint.sh        # Linter v1.3.1
└── build/                    # Compiled JS (gitignored)

零外部依赖 除了用于模式验证的MCP SDK和Zod之外。带有严格模式的TypeScript。编译到ESM。

看 praxis-mcp/README.md 获取包含输入模式和示例响应的完整工具参考。

______________________________________________________________________

基金会：为什么选择文件系统？

MCP服务器是Praxis扩展的方式。但文件系统就是这样 *生存。*

上面的每一种方法选择——上下文链、工作订单、四阶段生命周期——都是建立在一个深思熟虑的基础上的：文件系统。不是数据库。不是API。不是SaaS平台。文件和文件夹。

• 零依赖 --适用于任何有文件系统的地方。没有安装，没有帐户，没有订阅。
• Git友好 --The dev/ 文件夹可以被跟踪（或者私有项目可以被忽略）。完整版本历史记录免费。
• 人工智能原生 --每个AI代理都可以读写文件。并非每个AI代理都能调用API或查询数据库。
• 人类可读 --在任何文本编辑器中打开任何文件。不需要特殊的工具来了解项目状态。
• 便携的 --复制 dev/ 文件夹到新机器、新项目、新团队。它只是工作。
• 透明 --没有隐藏状态。一切都是可见的、可审计的和可区分的。

这很重要，因为这意味着 Praxis在没有MCP服务器的情况下工作。 任何能够读取文件的AI都可以遵循这种方法。init文档包含所有内容——规则、文件夹结构、会话协议。不支持MCP的AI仍然可以读取 CLAUDE_INIT.md，按照说明操作完全受控的Praxis工作流。

MCP服务器不会取代此基础。它 加速 文件就是国家。工具就是界面。您可以在任何级别运行Praxis：

每一层都增加了自动化。它们都没有添加锁定功能。

______________________________________________________________________

起源故事

Praxis是数千小时将最有能力的代理LLM推向实际项目极限的巅峰。不是玩具演示。不是教程应用程序。真正的基础设施构建、真正的web应用程序、真正的多代理工作流程，其中错误花费数小时，上下文丢失花费数天。

但这种方法论并不仅仅来自人工智能。它来自一个意想不到的地方： 物业管理。

多年来管理建筑项目、协调承包商、跟踪多个地点的工作订单以及维护合规审计跟踪，这些运营经验已融入Praxis的每个部分。工作订单模式？几十年来，建筑业就是这样跟踪任务的。草案/公布的墙？这就是物业经理处理租赁文件的方式——草稿是内部的，已发布的文件会交给租户。上下文链？这是你留给下一个值班经理的交接单，这样就不会有任何遗漏。

见解很简单： 人工智能代理与人类团队有着相同的协调问题。 他们忘记了会议之间的背景。他们不知道其他特工在做什么。他们缺乏单一的真相来源。他们无法验证任务是否实际完成。这些都是运营管理中已解决的问题，只是尚未应用于人工智能开发。

Praxis连接两个世界：

• 组织纪律 真实世界的项目管理——工作订单、审计跟踪、移交协议、质量门
• 技术能力 现代人工智能代理——代码生成、研究、架构分析、多代理编排

其结果是一种方法论，在这种方法论中，人类和人工智能代理平等协作，各自弥补对方的局限性。人工智能有无限的耐心和处理能力，但没有持久的记忆。人类拥有制度知识和决策权，但带宽有限。Praxis为双方提供了一个共享的工作空间，在这个工作空间中，上下文得以保留，工作被跟踪，没有任何东西丢失。

进化告诉了这个故事： v1.1 为AI代理提供了结构化文件夹和标记文档。 v1.2 添加 praxis-lint --执行规则的50个自动检查。 v1.3 添加了MCP服务器——将方法论转化为人工智能不仅遵循的东西的原生工具 *电话。* v1.3.1 强化了整个堆栈：基于通道的子项目组织、补丁工作订单、N/A标准识别、CLI安装程序和安全模型——所有这些都在上游之前在真实的多代理项目上进行了战斗测试。

文件系统是基础。门楣是护栏。 MCP服务器是接口。 他们共同使Praxis成为第一个自我管理的人工智能开发方法。

这种方法中的每一条规则都存在，因为它的缺失在实际项目中造成了真正的问题。没有什么是理论性的。一切都是 *实践*.

______________________________________________________________________

许可证

MIT许可证。看 许可证 了解详情。

MIT许可证意味着您可以自由使用、修改和分发Praxis，包括在商业项目中。唯一的要求是包括版权声明。这与React、Next.js和大多数主要开源开发工具使用的许可证相同。

______________________________________________________________________

由...创建 路易斯·法克斯, 2026.

faxas.net/方法论 --完整的方法论解释、示例和资源。

*“理论变成实践的过程。”* *--亚里士多德，论πρᾶξις*