Building a Knowledge Service

A knowledge service Agent is a resident Agent that uses the Context Skills to produce, update and answer from a team's knowledge, with people reviewing at the key decision points. It is not a new Agent platform: you take an existing Agent runtime and give it the Context Skills plugin, a Bot prompt and remote retrieval.

The same Skills work anywhere — in a hosted Agent runtime or in a local coding Agent such as Claude Code, Codex or Cursor. A resident service pays off for knowledge a team shares: production involves a lot of searching and confirmation, and questions need an answer at any time. Knowledge for a small module can simply live with its repository under docs/.

Status. The community edition does not ship a Bot implementation. The runtime and service interface below describe the design planned for this site's own Bot. The Skills, the flows and the interaction lessons have been proven in practice.

Layers

flowchart TB
  entry["Entrances<br/>website chat, team chat Bot,<br/>scheduled task, API"] --> service["Service layer<br/>session API"]
  service --> agent["Agent runtime<br/>one isolated sandbox per session"]
  agent --> skills["Context Skills plugin"]
  skills --> base["context CLI, Agent Graph,<br/>Source Graph MCP, Git"]
  base --> out["Knowledge repository,<br/>package, website"]

Layer	Made of	Responsible for
Entrances	Website chat, team chat Bot, scheduled tasks, API calls	Questions, production or update requests, routine patrols
Service layer	Session API	Authentication, rate limiting, one runtime per session, relaying the event stream, rendering results as web messages or chat cards, collecting ratings
Agent	Hosted Agent runtime	One isolated sandbox per session; system prompt plus the Bot prompt; picks Skills by intent
Skills	Context Skills plugin	Production: context, context-plan and the four Indexers. Retrieval: context-inspect-search. Same-repository docs: context-repo-content
Foundations	context CLI with Agent Graph, Source Graph MCP, Git	Advancing and resuming the workflow, reading code remotely by commit, committing the Context knowledge workspace
Outputs	Knowledge repository (Git), knowledge package, documentation site	Published together after a build

Three flows

Flow	Steps
Production	Prepare the environment (restore the workspace and source versions, context) → plan (the Bot prompt recognizes intent, context-plan) → capture (code pinned to a commit, documents snapshotted) → write (Indexer Skills, each section with source references) → review (references checked automatically, people review the diff report) → build and publish → archive (version and changelog)
Retrieval	Prepare (mount the plugin and packages) → recognize a question → find knowledge (context-inspect-search: indexes first, then page bodies and evidence) → if knowledge is not enough, read originals by commit through Source Graph → answer conclusion-first with sources
Update	Triggered by a request in chat, by a gap found while answering and confirmed by the user, or by a scheduled patrol → assess impact (compare old and new source versions, find affected articles) → revise only the affected parts and their references → people review the diff report → publish → report changed articles and the new version

Choosing a runtime

Any hosted Agent runtime with an isolated sandbox per session works; choose on:

• Sandbox start time — cold start dominates the first answer.
• Session length limit — production sessions run long.
• File system persistence — whether the Context knowledge workspace and installed tools survive between sessions.
• Egress control — which sources and services the sandbox may reach.

Keep the service layer on a generic session interface — create a session, send a message, read the event stream, end the session — so that switching runtimes does not change the Skills.

Configuring the Bot

The Bot prompt is the Bot's trusted instance configuration. Use it to:

• Set review policy. A Bot setting can override any context.gate.* switch for every task it runs; precedence is Bot, then fully managed, then ordinary defaults, and an authorized task-scoped override of the two review switches still wins for that task. See Managed Mode and Review Policy.
• Set retrieval order. CONTEXT_QUERY_SOURCE_MODE (repo-first, package-first, dual) and CONTEXT_QUERY_ACCESS_MODE (auto, remote, local) come from the host or Bot configuration. See Asking Questions.
• Describe patrols. Scheduled tasks need their own prompts; see Scheduled Updates.

How people interact with the Bot day to day is in Using the Bot in Team Chat.

搭建知识服务

知识服务 Agent 是一个常驻 Agent，它借助 Context Skills 生产、更新团队知识并据此回答问题，人在关键决策点上审核。它不是一个新的 Agent 平台：你只需拿一个现有的 Agent 运行时，为它配上 Context Skills 插件、Bot 提示词和远程检索。

同一套 Skill 在任何地方都能用——无论是托管的 Agent 运行时，还是 Claude Code、Codex、Cursor 这样的本地编码 Agent。常驻服务的价值在于团队共享的知识：生产过程需要大量检索和确认，问题也需要随时有人回答。小模块的知识直接放在其仓库的 docs/ 下即可。

状态。 社区版不提供 Bot 实现。下文的运行时与服务接口描述的是本站自有 Bot 的规划设计。Skill、流程和交互经验已在实践中得到验证。

分层

flowchart TB
  entry["入口<br/>网站对话、团队聊天 Bot、<br/>定时任务、API"] --> service["服务层<br/>会话 API"]
  service --> agent["Agent 运行时<br/>每个会话一个隔离沙箱"]
  agent --> skills["Context Skills 插件"]
  skills --> base["context CLI、Agent Graph、<br/>Source Graph MCP、Git"]
  base --> out["知识仓库、<br/>知识包、网站"]

层	组成	职责
入口	网站对话、团队聊天 Bot、定时任务、API 调用	提问、生产或更新请求、例行巡检
服务层	会话 API	鉴权、限流、每个会话一个运行时、转发事件流、把结果渲染为网页消息或聊天卡片、收集评价
Agent	托管 Agent 运行时	每个会话一个隔离沙箱；系统提示词加 Bot 提示词；按意图选择 Skill
Skill	Context Skills 插件	生产：context、context-plan 和四个 Indexer。检索：context-inspect-search。同仓库文档：context-repo-content
基础	context CLI 与 Agent Graph、Source Graph MCP、Git	推进和恢复工作流、按提交远程读取代码、提交 Context 知识工作区
产出	知识仓库（Git）、知识包、文档站点	构建后一并发布

三条流程

流程	步骤
生产	准备环境（恢复知识工作区和来源版本，context）→ 规划（Bot 提示词识别意图，context-plan）→ 采集（代码固定到提交，文档生成快照）→ 编写（Indexer Skill，每一节都带来源引用）→ 审核（自动检查引用，人审核 Diff 报告）→ 构建并发布 → 归档（版本与 Changelog）
检索	准备（挂载插件和知识包）→ 识别问题 → 查找知识（context-inspect-search：先查索引，再看页面正文和证据）→ 知识不够时，通过 Source Graph 按提交读取原文 → 结论先行并附来源作答
更新	由聊天中的请求、回答时发现并经用户确认的缺口，或定时巡检触发 → 评估影响（对比新旧来源版本，找出受影响的文章）→ 只修订受影响的部分及其引用 → 人审核 Diff 报告 → 发布 → 报告变更的文章和新版本

选择运行时

任何为每个会话提供隔离沙箱的托管 Agent 运行时都可以；选择时看这几点：

• 沙箱启动时间——冷启动是首次回答耗时的主要来源。
• 会话时长上限——生产会话往往运行很久。
• 文件系统持久化——Context 知识工作区和已安装的工具能否在会话之间保留。
• 出网控制——沙箱可以访问哪些来源和服务。

让服务层基于通用的会话接口——创建会话、发送消息、读取事件流、结束会话——这样更换运行时不会影响 Skill。

配置 Bot

Bot 提示词是 Bot 受信任的实例配置。用它来：

• 设置审核策略。 Bot 设置可以为它运行的每个任务覆盖任意 context.gate.* 开关；优先级依次是 Bot、全托管模式、普通模式默认值，而经授权、仅作用于单个任务的两个审核开关覆盖，在该任务中仍然优先。参见托管模式与审核策略。
• 设置检索顺序。 CONTEXT_QUERY_SOURCE_MODE（repo-first、package-first、dual）和 CONTEXT_QUERY_ACCESS_MODE（auto、remote、local）来自宿主或 Bot 配置。参见提问。
• 描述巡检。 定时任务需要各自的提示词；参见定时更新。

团队日常如何与 Bot 交互，见在团队聊天中使用 Bot。