Context for AI

Appearance

Architecture Overview ​

The parts ​

mermaid
flowchart TB
  user["You"] --> agent["Your Agent"]
  subgraph plugin["Agent plugin"]
    entries["Entry skills"]
    indexers["Indexer skills"]
  end
  agent --> plugin
  plugin --> cli["context CLI"]
  subgraph runtime["Local runtime"]
    cli --> provider["Workflow Provider"]
    cli --> extract["Extractors"]
    cli --> sdk["SDK declarations"]
  end
  cli --> ws["Context knowledge workspace"]
  ws --> out["Package, site, LLM Docs"]
PartRole
Agent entriesThin skills that tell the Agent how to start or continue a Context knowledge workspace and how to follow the current step
Indexer skillsProvider skills that read one kind of source and write source-grounded articles
context CLIObserves the knowledge workspace, captures sources, runs extractors, validates evidence, applies reviews and builds outputs
Workflow ProviderThe work contract evaluated by Agent Graph: legal steps, Gates and required reading
SDK (@c4a/context)The declaration surface for a knowledge workspace's src/index.ts: sources, phases and packages
ExtractorsParser packages that turn code and interface definitions into structural facts
Evidence pluginAn optional WebAssembly plugin that lets Source Graph attach knowledge sections to code reads

Local-first by design ​

There is no server, daemon, database, hosted API or web frontend in Context. The CLI reads declared sources, writes knowledge workspace files, validates invariants and produces portable packages. Everything a team needs to inspect lives in the knowledge workspace and can be committed to Git; a hosted Agent or Bot runs the same CLI.

Who does what ​

The Agent performs semantic work: reading evidence, proposing structure and content, explaining decisions. The CLI performs deterministic work and never calls an LLM. The user owns the goal, source permissions, structure choices and review decisions. Keeping these apart is what makes a long workflow repeatable — see Why a Workflow.

How a request travels ​

  1. The Agent entry runs context entry, which resolves initialization, relocation or the current workflow.
  2. The CLI observes knowledge workspace facts and asks the Provider for the current Route: the step, its reading list, any Gate and the exact commands.
  3. The Agent reads, decides and runs one selected action.
  4. The knowledge workspace changes, and the CLI evaluates again.

Details are in Workflow Execution; the stages a source passes through are in Knowledge Lifecycle; package boundaries are in Module Layout.

总体架构 ​

组成部分 ​

mermaid
flowchart TB
  user["你"] --> agent["你的 Agent"]
  subgraph plugin["Agent 插件"]
    entries["入口技能"]
    indexers["Indexer 技能"]
  end
  agent --> plugin
  plugin --> cli["context CLI"]
  subgraph runtime["本地运行时"]
    cli --> provider["工作流 Provider"]
    cli --> extract["提取器"]
    cli --> sdk["SDK 声明"]
  end
  cli --> ws["Context 知识工作区"]
  ws --> out["知识包、站点、LLM Docs"]
组成部分作用
Agent 入口轻量技能，告诉 Agent 如何开始或继续一个 Context 知识工作区，以及如何执行当前步骤
Indexer 技能Provider 提供的技能，每种读取一类来源并写出有来源依据的文章
context CLI观察知识工作区、采集来源、运行提取器、校验证据、应用审核结果并构建产出
工作流 Provider由 Agent Graph 求值的工作约定：合法步骤、Gate 和必读资料
SDK（@c4a/context）知识工作区 src/index.ts 的声明接口：来源、阶段和知识包
提取器解析器包，把代码和接口定义转换为结构化事实
证据插件可选的 WebAssembly 插件，让 Source Graph 在读取代码时附上相关知识小节

本地优先的设计 ​

Context 没有服务器、守护进程、数据库、托管 API 或 Web 前端。CLI 读取声明的来源、写入知识工作区文件、校验不变量，并产出可移植的知识包。团队需要检查的一切都在知识工作区里，可以提交到 Git；托管的 Agent 或 Bot 运行的也是同一个 CLI。

分工 ​

Agent 负责语义工作：阅读证据、提出结构和内容、解释决策。CLI 负责确定性工作，从不调用 LLM。用户掌握目标、来源权限、结构选择和审核决定。正是这种分离让长流程可以重复执行——参见为什么是工作流。

一次请求如何流转 ​

  1. Agent 入口运行 context entry，由它判断是初始化、迁移位置还是进入当前工作流。
  2. CLI 观察知识工作区的事实，向 Provider 请求当前 Route：步骤、阅读清单、可能的 Gate 以及确切的命令。
  3. Agent 阅读、决策，并执行选定的一个动作。
  4. 知识工作区发生变化，CLI 再次求值。

细节见工作流运行；来源经历的各个阶段见知识生命周期；包的边界见模块划分。