企业官网建设流程全解析

导读

OpenJarvis 将“可持久化、可调度的自主代理”抽象为Operator（算子），而sentinel（哨兵）就是其中面向信息监控的典型实现：它基于一份精确定义的系统提示词（sentinel_prompt.md）与配套的 TOML 清单（sentinel.toml），通过web_search、http_request、memory_*与知识图谱工具，对社交平台、新闻源与指定网页进行周期巡检、变化检测与 1-10 分显著性评分，仅对达到阈值的重要变化生成告警。读完本文，你将掌握 sentinel 提示词的完整行为协议、operator 清单的每个配置项含义、从加载到调度的底层实现链路，以及如何用jarvis operators命令行把这套哨兵部署到你自己的设备上。

一、Sentinel 在 OpenJarvis 中的定位

OpenJarvis 的 recipes（配方）体系把代理配置统一抽象为 TOML 文件，分为两类生命周期：

• discrete（离散型）：一次性或面向基准测试的代理；
• operator（算子型）：持久化、按调度周期运行的自主代理。

sentinel属于 operator 类型。它和correspondent（消息分类）、news_briefing（新闻摘要）、repo_watcher（仓库监控）等算子一同存放在 src/openjarvis/recipes/data/operators/ 目录下。从源码结构看，sentinel 的关注点是外部信息源的变化检测与告警，与其对应的还有模板目录中的monitor模板（src/openjarvis/templates/data/monitor.toml），说明“监控-告警”是一类被官方模板化的常见场景。

二、Sentinel Operator 完整配置解读

sentinel 的行为由两部分组成：TOML 清单负责“怎么跑”，Markdown 提示词负责“干什么”。先看清单全文（src/openjarvis/recipes/data/operators/sentinel.toml）：

[operator] name = "sentinel" version = "0.1.0" description = "Monitoring sentinel agent — watches social media, news, and web sources for changes relevant to user-defined topics and produces scored alerts" [operator.agent] max_turns = 15 temperature = 0.3 tools = ["web_search", "http_request", "memory_store", "memory_search", "kg_add_entity", "think"] system_prompt_path = "sentinel_prompt.md" [operator.schedule] type = "cron" value = "0 */2 * * *"

逐项拆解：

其中0 */2 * * *是标准 cron 表达式：分=0，时=2 的倍数，即每天 0、2、4……22 点运行，实现“全天候、低频率”的巡检节奏。

注意：此清单使用[operator]顶层键，属于旧式 operator 清单格式。从 src/openjarvis/recipes/loader.py 的加载逻辑看，loader 会自动检测"operator" in data and "recipe" not in data并把它转换统一的Recipe数据结构，因此新老格式可以共存。同目录下的inbox_triage.toml、news_briefing.toml则使用了[recipe]+kind = "operator"的新式写法。

三、Sentinel 系统提示词：监控哨兵的行为协议

系统提示词是 sentinel 的“灵魂”。sentinel_prompt.md 全文定义了 8 个部分，构成一个完整闭环的监控协议。

3.1 角色与目标（Objective）

提示词开篇将代理定位为：

You are a monitoring sentinel agent running on-device.

即运行在用户自己设备上的监控哨兵。目标明确为四件事：监控与用户定义主题相关的在线信息源变化、发现热门讨论与情绪转向、捕捉突发新闻、跟踪竞争对手动态——并且只在发现值得关注的重大变化时产出带评分的告警（scored alerts），避免打扰。

3.2 监控源清单（Sources to Monitor）

提示词要求哨兵跨以下平台与源类型搜索：

• Twitter/X：热门话题标签、有影响力的账号、病毒式传播的帖子；
• Reddit：相关 subreddit 中的热门帖、评论情绪；
• Mastodon：联邦化讨论、趋势话题；
• Google Trends：上升中的搜索词、突发话题；
• RSS 订阅源：来自指定 feed 的新闻文章与博客；
• 指定 URL：用户标记的直接监控页面。

实现层面，提示词明确要求用web_search跨平台查询、用http_request抓取特定页面或 feed。这两者对应的工具实现均存在于仓库中：src/openjarvis/tools/web_search.py 与 src/openjarvis/tools/http_request.py。

3.3 七步监控流程（Monitoring Process）

完整流程如下，每一步都有明确的工具映射：

1. 回顾上次状态：用memory_search检索上一轮巡检发现，作为变化检测的基线（baseline）；
2. 规划搜索：用think规划本周期最高效的查询组合，优先选择历史上产出过有效发现的源；
3. 执行搜索：针对用户主题逐源查询，先聚焦高信号源；
4. 检测变化：与基线对比，寻找四类信号——未见过的全新讨论/文章、情绪或体量的显著变化、突发新闻或活动骤增、新实体（人物/公司/产品）进入话题；
5. 评分显著性：按 1-10 分制给每条发现打分；
6. 记录发现：用memory_store带时间戳持久化全部发现，用kg_add_entity在知识图谱中登记关键实体与事件；
7. 生成告警：只对 7 分及以上的发现产出告警。

3.4 显著性评分标准（Significance Scoring 1-10）

评分由三个维度加权构成，总分 10 分：

7分既是告警门槛，也是“防告警疲劳（alert fatigue）”的节流阀——只有真正重要的变化才会打断用户。

3.5 告警输出格式（Alert Output Format）

每条告警必须遵循固定模板，便于下游解析与聚合：

## Alert: [Brief title] - **Topic**: [User-defined topic this relates to] - **Source**: [Platform and specific URL] - **Significance**: [Score]/10 (Relevance: X, Magnitude: Y, Impact: Z) - **Summary**: [2-3 sentence description of the finding and why it matters] - **Link**: [Direct URL to the source] - **First detected**: [Timestamp]

七个字段分别承担标题、主题归属、来源、得分明细、摘要、直达链接与首次发现时间，形成了结构化、可机器读取的告警契约。

3.6 周期结束总结（End-of-Cycle Summary）

每个巡检周期收尾时，哨兵需输出摘要，覆盖：

• 检查过的源总数；
• 新增发现数（全部分数）；
• 生成的告警数（7 分及以上）；
• 无新活动的主题；
• 对监控范围（scope）的调整建议。

这一小节让每次运行既留痕又自省，为长期调优提供依据。

3.7 运行准则（Guidelines）

• 全量入库：即使低于告警阈值，所有发现也要带时间戳存入记忆，支撑长期趋势分析；
• 零结果主题：某主题持续无结果时，用think建议改进的检索词或替代来源；
• 节能优先：若某来源连续 3 个周期无有效产出，降低其检查频率——这呼应了 OpenJarvis “Personal AI, On Personal Devices” 的本地设备节能理念；
• 绝不编造：搜索无结果就如实报告，禁止伪造发现；
• 附上链接：尽可能附带直达来源 URL。

四、底层实现链路：从 TOML 到运行中的哨兵

4.1 Recipe 加载与提示词解析

src/openjarvis/recipes/loader.py 是配方的统一加载入口。对[operator]旧式清单，_load_operator_as_recipe（loader.py）会做关键一步：把system_prompt_path解析为相对 TOML 文件所在目录的绝对路径并读取全文，随后填充到Recipe.system_prompt。这正是sentinel.toml中写system_prompt_path = "sentinel_prompt.md"即可生效的原因——提示词与清单放在同一目录下。

4.2 转换为 OperatorManifest

Recipe通过 src/openjarvis/recipes/composer.py 的recipe_to_operator纯函数转换为OperatorManifest（定义见 src/openjarvis/operators/types.py）。转换时max_turns缺省为 20、temperature缺省为 0.3、schedule_value缺省为"300"；若清单缺少[schedule]段会直接抛ValueError——operator 必须声明调度。

4.3 OperatorManager 生命周期

src/openjarvis/operators/manager.py 中的OperatorManager负责全部生命周期操作：

• register / discover：登记单个 manifest，或扫描目录批量注册；
• activate：通过TaskScheduler.create_task创建调度任务，任务 id 固定为operator:{id}（如operator:sentinel），已激活则幂等返回；每次 tick 的提示词为[OPERATOR TICK] Execute your operational protocol.，agent 类型为operative；
• deactivate / pause / resume：分别取消、暂停、恢复调度任务；
• run_once：立即执行一次 tick（开发与测试用）；
• status：合并 manifest 信息与调度器任务状态，展示next_run、last_run；
• collect_metrics：按 manifest 声明的metrics列表从 TelemetryAggregator 汇总total_calls、total_energy_joules、avg_throughput_tok_per_sec等指标——sentinel 清单未声明 metrics，但该机制为所有 operator 提供了能耗与性能观测能力。

4.4 调度器

调度由 src/openjarvis/scheduler/scheduler.py 承担，ScheduledTask.schedule_type支持"cron" | "interval" | "once"，schedule_value对应 cron 表达式、间隔秒数或 ISO 时间。sentinel 的cron+0 */2 * * *即在此执行；任务与运行记录持久化在 SQLite 中（SchedulerStore，见 src/openjarvis/scheduler/store.py）。

五、哨兵工具链：六把“武器”的源码级解析

sentinel 被授予 6 个工具，逐一对应仓库中的真实实现：

1. web_search（src/openjarvis/tools/web_search.py）：引擎按OPENJARVIS_WEB_SEARCH_ENGINE环境变量显式选择（auto/youcom/tavily/duckduckgo/serply）。auto模式优先 API 引擎：设置了TAVILY_API_KEY用 Tavily、YOUDOTCOM_API_KEY用 You.com 付费档、SERPLY_API_KEY用 Serply（Google SERP 代理），都没有则回落到 You.com 免密钥免费档（按 IP 限速），DuckDuckGo 是最后兜底。这意味着全新安装、零配置也能跑通网络搜索。

2. http_request（src/openjarvis/tools/http_request.py）：抓取指定页面与 RSS feed。实现中内置SSRF 防护（调用openjarvis.security.ssrf.check_ssrf），命中保护规则会返回SSRF protection blocked request，避免哨兵被诱导访问内网地址——这对“监控任意 URL”的场景是必要的安全兜底。

3. memory_store/memory_search（src/openjarvis/tools/storage_tools.py）：分别持久化发现（带时间戳）与检索上一轮基线。未配置 memory 后端时会返回No memory backend configured.，提示需要先在系统配置中启用记忆后端。

4. kg_add_entity（src/openjarvis/tools/knowledge_tools.py）：向知识图谱登记实体，spec要求entity_id、entity_type、name三个必填参数，声明了memory:write能力。哨兵用它记录话题中涌现的新人物、新公司、新产品。

5. think：规划型工具，用于步骤 2 的搜索规划与零结果主题的检索词优化。

其中memory_store、kg_add_entity需要对应的记忆/图谱后端可用；能力声明（required_capabilities）由 src/openjarvis/security/capabilities.py 承载，与安全子系统联动。

六、命令行实操：部署与运维哨兵

CLI 层提供了完整的 operator 管理命令（实现见 src/openjarvis/cli/operators_cmd.py，注册于 src/openjarvis/cli/init.py）：

# 查看所有已发现 operator 及其调度状态 jarvis operators list # 查看 sentinel 的详细清单信息（工具、调度、提示词预览） jarvis operators info sentinel # 激活 sentinel —— 创建 cron 调度任务（id: operator:sentinel） jarvis operators activate sentinel # 立即执行一次巡检（开发调试用） jarvis operators run sentinel # 查看最近运行日志 jarvis operators logs sentinel # 暂停 / 恢复 / 停用 jarvis operators pause sentinel jarvis operators resume sentinel jarvis operators deactivate sentinel # 把自定义清单安装到 ~/.openjarvis/operators/ jarvis operators install /path/to/my_sentinel.toml

operators list以表格展示 id、名称、调度表达式（schedule_type:schedule_value）、前 3 个工具与版本号；operators logs直接查询 SQLite 存储，展示每次运行的起止时间与成功状态。

此外，src/openjarvis/cli/compose_cmd.py 提供统一配方入口：

# 按类型过滤列出配方 jarvis compose list --kind operator

清单说明：operator 类命令会通过SystemBuilder().scheduler(True).sessions(True).build()构建带调度器与会话的系统实例，若配置中未启用[scheduler]，activate会抛出TaskScheduler not available的RuntimeError（见 manager.py）。

七、定制你自己的 Sentinel

要让哨兵监控你的主题，有两处可改：

1. 行为层：复制一份 sentinel_prompt.md，把 Objective 中 “user-defined topics” 替换为具体主题（如品牌名、竞品、技术栈关键词），并按需调整监控源清单与告警阈值（7分可上下浮动以平衡灵敏度与打扰度）。

2. 调度与资源层：复制 sentinel.toml，修改[operator.schedule]的value（如改为interval+value = "3600"每小时一次，或改 cron 为0 8 * * *仅每天早晨巡检），并可通过调整max_turns、temperature控制单次运行成本与输出稳定性。新式[recipe]+kind = "operator"格式同样受支持，还能额外声明[intelligence]、[engine]、[learning]等五要素。

随后用jarvis operators install安装到用户目录，jarvis operators activate <name>激活，即可让哨兵在你自己的设备上按既定节奏持续巡检。

八、设计要点与注意事项

• 防告警疲劳是核心设计：评分门槛7、低频 cron、max_turns=15的轮数上限，三者共同把“持续监控”约束在低打扰区间；
• 变化检测依赖记忆基线：memory_search的基线对比是流程第 4 步的前提，因此必须保证记忆后端可用，否则变化检测会退化为“全量新发现”；
• 诚实报告：提示词明确禁止编造发现，无结果时如实报告，这保证了memory_store中沉淀的数据可用于长期趋势分析；
• 网络访问需按环境配置：web_search依赖环境变量选择引擎（OPENJARVIS_WEB_SEARCH_ENGINE、各*_API_KEY），http_request受 SSRF 防护约束，部署在受限网络时需要提前确认可达性；
• 安全联动：工具的required_capabilities与 src/openjarvis/security/capabilities.py 的能力检查联动，自定义 operator 时如扩展工具集，需同步评估能力声明。

从一份 74 行的系统提示词出发，sentinel 串起了 OpenJarvis 的 recipes 配方体系、operators 生命周期管理、cron 调度器、工具注册表与记忆/知识图谱后端——它就是“个人设备上的自主信息哨兵”这一场景的完整参考实现，既可直接部署，也可作为自定义监控代理的模板。