Agent-Skills-for-Context-Engineering 研究循环持续运行实战用 macOS launchd 搭建无人值守的科研守护进程【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering本指南是 researcher/runbooks/continuous-operation.md 的完整实战解读面向需要在 macOS 上以守护进程方式长期运行「研究 → 提案 → 技能演进」闭环的开发者。读完你将掌握四类定时任务的调度语义、researcher/orchestration/config.json中全部预算与间隔参数的调优方法、install.sh/uninstall.sh的安装原理以及如何通过 dashboard、parked-review、daily snapshot 等人工审查面在安全边界内接管循环。背景为什么需要一个持续运行的科研守护进程在 Agent-Skills-for-Context-Engineering 仓库中researcher 目录 承载了一套自主研究框架从源注册表发现候选资料、抓取主证据、评估机制、起草技能提案直到产出可评审的仓库变更。单次运行可以由人驱动见 autonomous-research-loop.md但要让「研究到技能」的闭环连续数天自动推进就需要一个不依赖终端会话、能在登录前后存活的后台调度系统。continuous-operation runbook 给出的方案是macOS launchd 作为守护载体四个 Python 循环脚本作为执行单元一个 JSON 配置统一管理全部节奏与预算。整个体系不调用任何 LLM 或付费 API把需要人类判断的节点统一「停放park」到审查面从而在无人值守的同时守住安全边界。谁在跑四类任务的职责与频率runbook 将运行负载划分为四个脚本各自节奏与职责如下频率定义可在researcher/orchestration/config.json中调整见下文Job频率职责loop_step.py每 10 分钟从 inbox 拉取候选将一条活跃 run 向前推进一个状态把需要人类或 judge 评审的 run 停放起来loop_discover.py每天两次本地时间 05:00 与 17:00从配置的 feeds 中把新的候选源追加进 inboxloop_daily.py每天一次本地时间 06:30运行仓库校验、激活用例、基准评测写入带日期的快照标记到期需复审的可变声明loop_status.py跟随每次loop_step与loop_daily执行刷新 dashboard 与停放审查面从 launchd plist 可以看出这套分工在系统层的落地方式com.context-engineering.loop-step.plist 使用StartInterval600 秒实现固定 10 分钟间隔com.context-engineering.loop-discover.plist 使用StartCalendarInterval数组声明 05:00 与 17:00 两个触发点com.context-engineering.loop-daily.plist 使用StartCalendarInterval声明每日 06:30。三个 plist 均设置RunAtLoad为false安装后不立即触发首轮等待计划时间点、显式指定WorkingDirectory为仓库根目录并注入包含/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin的PATH保证脚本在 launchd 的受限环境中仍能找到python3与常用工具。预算体系循环如何自我限流所有调度与预算都集中在 researcher/orchestration/config.json。runbook 给出的默认预算如下max active runs3max runs per day6max parked12max failures per day5max inbox size200当任意预算被超出时循环停止执行破坏性工作只保留记账bookkeeping行为直到人类介入评审。这是整套系统的核心安全机制宁可空转不可越界。从配置文件可以进一步看到预算之外的控制维度intervalsloop_step_minutes: 10、loop_discover_hours: 12、loop_daily_hour_utc: 6是脚本内部调度依据human_review定义了触发停放的判定集合——park_on_verdicts为[HUMAN_REVIEW, REJECT]park_on_novelty为[human_review, likely_duplicate]并指定停放通知文件为researcher/reports/parked-review.mdfeedsmanual_seed指向 researcher/discovery/manual-seed.jsonlenable_parallel_deep_research与enable_web_search默认均为false保持纯离线手动种子模式limitsdiscovery_max_new_per_run: 8单轮发现最多新增 8 条、loop_step_max_advances: 1每轮 step 最多推进 1 个状态mode为dry-run配置中_mode_doc注明该字段预留给未来可能的付费 LLM feedsjudge/synthesisHTTP 抓取能力由loop_step的--allow-fetch单独控制。需要特别说明runbook 中loop_daily的 06:30 是「本地时间」而配置里loop_daily_hour_utc使用 UTC 语义。实际调度以 launchd plist本地时区 06:30与脚本内部逻辑为准修改频率时务必同时核对 config.json 与对应 plist避免两处不一致。安装install.sh 做了什么安装只需执行一条命令researcher/orchestration/launchd/install.sh对照 install.sh 源码脚本按以下步骤工作替换仓库路径用sed s|__REPO_ROOT__|${REPO_ROOT}|g把三个 plist 模板中的占位符替换为实际的仓库绝对路径写入用户 LaunchAgents目标目录为~/Library/LaunchAgents/TARGET_DIR${HOME}/Library/LaunchAgents安装前先mkdir -p创建目录与researcher/reports/logs日志目录引导到当前用户 agent 域先launchctl bootout gui/$(id -u)清理旧实例失败静默忽略再launchctl bootstrap gui/$(id -u)加载新 plist启用标签使其跨登录会话存活launchctl enable gui/$(id -u)/label三个标签分别为com.context-engineering.loop-step、com.context-engineering.loop-discover、com.context-engineering.loop-daily。脚本顶部注释明确声明不会以 root 运行任何东西只写用户级 LaunchAgents 并引导到当前用户域符合最小权限原则。安装完成后可用以下命令检查任务状态launchctl print gui/$(id -u)/com.context-engineering.loop-step日志落盘位置所有日志统一落在researcher/reports/logs/loop_step.log、loop_discover.log、loop_daily.log、loop_status.log各脚本追加的 JSON 结构化日志launchd-loop-step.out与launchd-loop-step.errdiscover/daily 同理launchd 捕获的原始标准输出与标准错误。从 run-loop-step.sh 可以看到日志链路的关键细节python3 researcher/scripts/loop_step.py --allow-fetch --json ${LOG_DIR}/loop_step.log 21 || true python3 researcher/scripts/loop_status.py --json ${LOG_DIR}/loop_status.log 21|| true是刻意为之loop_step在没有可推进工作时以退出码 78 结束见下文「手动操作」这属于正常状态不能中断紧随其后的 status 刷新。同时注意loop_step之后总是紧跟loop_status与 runbook 中「loop_status 搭乘每次 loop_step」的描述一致。卸载uninstall.shresearcher/orchestration/launchd/uninstall.shuninstall.sh 对三个标签逐一执行launchctl bootout gui/$(id -u)失败静默忽略并删除~/Library/LaunchAgents/下对应的 plist 文件之后循环不再被调度。卸载不会删除任何日志、快照或队列数据这些仍保留在仓库的researcher/reports/与researcher/queue/中供事后审计。手动操作不经过 launchd 直接驱动循环在调试或临时运行时可以直接执行循环脚本而不依赖 launchdpython3 researcher/scripts/loop_discover.py # 拉取新源进入 inbox python3 researcher/scripts/loop_step.py --allow-fetch # 推进一个状态 python3 researcher/scripts/loop_daily.py # 基准评测 快照 python3 researcher/scripts/loop_status.py # 刷新 dashboard其中--allow-fetch是关键开关对照 loop_step.py 的参数定义--allow-fetch是store_true型布尔参数开启后允许通过 Python 标准库urllib执行 HTTP GET 抓取不带该参数时循环会把需要源抓取的 run 停放起来等待人类处理。这保证了默认路径下守护进程不具备任何网络侧信道网络行为完全由显式开关授权。两个值得注意的行为细节所有脚本都支持--json参数输出结构化结果loop_step会print(json.dumps(result, indent2))便于脚本化消费loop_step在无事可做action no-op时返回退出码78这是正常信号而非错误launchd 包装脚本正是利用这一点与|| true配合实现「无工作时静默跳过」。loop_step.py的模块文档也强调默认--allow-fetch处于关闭状态非白名单的网络调用被禁止——这是安全模型的一部分。人工审查面每天该看哪些文件runbook 建议检查循环状态时阅读以下文件researcher/reports/status.md高层 dashboardresearcher/reports/parked-review.md等待评审人的 run 列表researcher/reports/snapshots/date.md每日快照researcher/reports/benchmark-history.jsonl追加式基准趋势记录researcher/queue/inbox.jsonl等待初始化的候选源researcher/queue/quarantine.jsonl被移出轮换的源。对照 loop_status.py 的实现dashboard 与停放审查面是程序化生成的脚本读取researcher/queue/parked.jsonl与researcher/queue/quarantine.jsonl汇总活跃 run、停放 run、隔离源数量当存在停放记录时把每个 run 的run_id、reason、parked_at渲染进researcher/reports/parked-review.md并输出parked_review_path供 JSON 消费。也就是说这些文件不是手工维护的清单而是循环状态的可读投影。停放 run 的处置动作ReasonActionneeds source retrieval手动抓取证据后执行research_loop.py retrieve --run-dir run --file evidenceneeds evaluation补全源评估 JSON 后执行research_loop.py evaluate --run-dir runneeds human or model action from state proposed完成提案后执行research_loop.py novelty --run-dir runneeds merge approval评审 PR 说明仅在明确批准后合并注意这些子命令都来自 researcher/scripts/research_loop.py是同一研究循环的命令入口与 autonomous-research-loop.md 中定义的init、retrieve、evaluate、novelty、promote-mechanisms等阶段一一对应。安全边界循环绝不越过的红线runbook 明确列出的安全约束均有源码与配置佐证循环从不调用 LLM 或付费 APIconfig.json中mode: dry-rundeep research 与 web search 均关闭抓取只走 stdliburllib抓取限时限量urllib请求带 30 秒超时与 1.5MB 上限防止单次抓取拖垮整个循环失败两次即隔离连续失败的源被移入researcher/queue/quarantine.jsonl退出轮换机制注册表只读机制注册表researcher/mechanisms/registry.jsonl只能通过research_loop.py promote-mechanisms更新且必须有记录的评审人循环本身不编辑它推送与合并始终由人类控制这延续了 autonomous-research-loop.md 的 PR 准备策略——Agent 最多准备 PR 草案合并需显式人类批准。这些约束共同构成了「自动发现、自动起草、人工裁决」的分层信任模型机器负责无风险的推进与记账所有涉及发布、合并、注册表变更的决策都保留给人类。每日节奏值守人员的最小例行流程runbook 给出了一套合理的值守节奏适用于运行该循环的人类操作者早晨阅读最新快照与 parked-review处理停放 run挑最多 3 条停放 run决定推进、拒绝或放弃批准机制提升对已具备发布条件的 run批准其机制提升promote-mechanisms保持循环运行让守护进程继续跑完当天。这套节奏把每日投入压缩到一次短暂检查夜间循环自动完成发现、抓取、评估、起草与校验白天人类只需消化停放队列做裁决。如果需要更细粒度的运行纪律如失败处理矩阵、PR 前置条件、上下文压缩前的手over 清单可进一步阅读同目录下的 autonomous-research-loop.md。排障要点结合源码运行中常见的几个信号与处置建议loop_step以退出码 78 结束属于「无工作」的正常信号不是故障若希望它安静运行保持 launchd 包装脚本中的|| true即可status.md显示 parked 数量持续上升说明有 run 停在了需要人类裁决的节点源抓取、评估、novelty 或合并此时loop_step只会做记账不会继续推进破坏性工作——这符合预算保护语义quarantine.jsonl出现新条目某个源连续失败两次被自动隔离可结合loop_step.log检查失败原因后决定是否重新纳入修改了config.json但调度未生效StartInterval与StartCalendarInterval定义在 launchd plist 中修改后需重新执行 install.sh 让 launchd 重载脚本内部的intervals与 plist 需要保持一致。通过本文所述的安装、预算、审查面与安全模型你可以将这套「自动研究 → 人工裁决」的循环稳定托管在 macOS 上让上下文工程技能的演进在没有人工干预的情况下持续数天推进同时把所有关键决策牢牢握在人类手中。【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Agent-Skills-for-Context-Engineering 研究循环持续运行实战：用 macOS launchd 搭建无人值守的科研守护进程
Agent-Skills-for-Context-Engineering 研究循环持续运行实战用 macOS launchd 搭建无人值守的科研守护进程【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering本指南是 researcher/runbooks/continuous-operation.md 的完整实战解读面向需要在 macOS 上以守护进程方式长期运行「研究 → 提案 → 技能演进」闭环的开发者。读完你将掌握四类定时任务的调度语义、researcher/orchestration/config.json中全部预算与间隔参数的调优方法、install.sh/uninstall.sh的安装原理以及如何通过 dashboard、parked-review、daily snapshot 等人工审查面在安全边界内接管循环。背景为什么需要一个持续运行的科研守护进程在 Agent-Skills-for-Context-Engineering 仓库中researcher 目录 承载了一套自主研究框架从源注册表发现候选资料、抓取主证据、评估机制、起草技能提案直到产出可评审的仓库变更。单次运行可以由人驱动见 autonomous-research-loop.md但要让「研究到技能」的闭环连续数天自动推进就需要一个不依赖终端会话、能在登录前后存活的后台调度系统。continuous-operation runbook 给出的方案是macOS launchd 作为守护载体四个 Python 循环脚本作为执行单元一个 JSON 配置统一管理全部节奏与预算。整个体系不调用任何 LLM 或付费 API把需要人类判断的节点统一「停放park」到审查面从而在无人值守的同时守住安全边界。谁在跑四类任务的职责与频率runbook 将运行负载划分为四个脚本各自节奏与职责如下频率定义可在researcher/orchestration/config.json中调整见下文Job频率职责loop_step.py每 10 分钟从 inbox 拉取候选将一条活跃 run 向前推进一个状态把需要人类或 judge 评审的 run 停放起来loop_discover.py每天两次本地时间 05:00 与 17:00从配置的 feeds 中把新的候选源追加进 inboxloop_daily.py每天一次本地时间 06:30运行仓库校验、激活用例、基准评测写入带日期的快照标记到期需复审的可变声明loop_status.py跟随每次loop_step与loop_daily执行刷新 dashboard 与停放审查面从 launchd plist 可以看出这套分工在系统层的落地方式com.context-engineering.loop-step.plist 使用StartInterval600 秒实现固定 10 分钟间隔com.context-engineering.loop-discover.plist 使用StartCalendarInterval数组声明 05:00 与 17:00 两个触发点com.context-engineering.loop-daily.plist 使用StartCalendarInterval声明每日 06:30。三个 plist 均设置RunAtLoad为false安装后不立即触发首轮等待计划时间点、显式指定WorkingDirectory为仓库根目录并注入包含/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin的PATH保证脚本在 launchd 的受限环境中仍能找到python3与常用工具。预算体系循环如何自我限流所有调度与预算都集中在 researcher/orchestration/config.json。runbook 给出的默认预算如下max active runs3max runs per day6max parked12max failures per day5max inbox size200当任意预算被超出时循环停止执行破坏性工作只保留记账bookkeeping行为直到人类介入评审。这是整套系统的核心安全机制宁可空转不可越界。从配置文件可以进一步看到预算之外的控制维度intervalsloop_step_minutes: 10、loop_discover_hours: 12、loop_daily_hour_utc: 6是脚本内部调度依据human_review定义了触发停放的判定集合——park_on_verdicts为[HUMAN_REVIEW, REJECT]park_on_novelty为[human_review, likely_duplicate]并指定停放通知文件为researcher/reports/parked-review.mdfeedsmanual_seed指向 researcher/discovery/manual-seed.jsonlenable_parallel_deep_research与enable_web_search默认均为false保持纯离线手动种子模式limitsdiscovery_max_new_per_run: 8单轮发现最多新增 8 条、loop_step_max_advances: 1每轮 step 最多推进 1 个状态mode为dry-run配置中_mode_doc注明该字段预留给未来可能的付费 LLM feedsjudge/synthesisHTTP 抓取能力由loop_step的--allow-fetch单独控制。需要特别说明runbook 中loop_daily的 06:30 是「本地时间」而配置里loop_daily_hour_utc使用 UTC 语义。实际调度以 launchd plist本地时区 06:30与脚本内部逻辑为准修改频率时务必同时核对 config.json 与对应 plist避免两处不一致。安装install.sh 做了什么安装只需执行一条命令researcher/orchestration/launchd/install.sh对照 install.sh 源码脚本按以下步骤工作替换仓库路径用sed s|__REPO_ROOT__|${REPO_ROOT}|g把三个 plist 模板中的占位符替换为实际的仓库绝对路径写入用户 LaunchAgents目标目录为~/Library/LaunchAgents/TARGET_DIR${HOME}/Library/LaunchAgents安装前先mkdir -p创建目录与researcher/reports/logs日志目录引导到当前用户 agent 域先launchctl bootout gui/$(id -u)清理旧实例失败静默忽略再launchctl bootstrap gui/$(id -u)加载新 plist启用标签使其跨登录会话存活launchctl enable gui/$(id -u)/label三个标签分别为com.context-engineering.loop-step、com.context-engineering.loop-discover、com.context-engineering.loop-daily。脚本顶部注释明确声明不会以 root 运行任何东西只写用户级 LaunchAgents 并引导到当前用户域符合最小权限原则。安装完成后可用以下命令检查任务状态launchctl print gui/$(id -u)/com.context-engineering.loop-step日志落盘位置所有日志统一落在researcher/reports/logs/loop_step.log、loop_discover.log、loop_daily.log、loop_status.log各脚本追加的 JSON 结构化日志launchd-loop-step.out与launchd-loop-step.errdiscover/daily 同理launchd 捕获的原始标准输出与标准错误。从 run-loop-step.sh 可以看到日志链路的关键细节python3 researcher/scripts/loop_step.py --allow-fetch --json ${LOG_DIR}/loop_step.log 21 || true python3 researcher/scripts/loop_status.py --json ${LOG_DIR}/loop_status.log 21|| true是刻意为之loop_step在没有可推进工作时以退出码 78 结束见下文「手动操作」这属于正常状态不能中断紧随其后的 status 刷新。同时注意loop_step之后总是紧跟loop_status与 runbook 中「loop_status 搭乘每次 loop_step」的描述一致。卸载uninstall.shresearcher/orchestration/launchd/uninstall.shuninstall.sh 对三个标签逐一执行launchctl bootout gui/$(id -u)失败静默忽略并删除~/Library/LaunchAgents/下对应的 plist 文件之后循环不再被调度。卸载不会删除任何日志、快照或队列数据这些仍保留在仓库的researcher/reports/与researcher/queue/中供事后审计。手动操作不经过 launchd 直接驱动循环在调试或临时运行时可以直接执行循环脚本而不依赖 launchdpython3 researcher/scripts/loop_discover.py # 拉取新源进入 inbox python3 researcher/scripts/loop_step.py --allow-fetch # 推进一个状态 python3 researcher/scripts/loop_daily.py # 基准评测 快照 python3 researcher/scripts/loop_status.py # 刷新 dashboard其中--allow-fetch是关键开关对照 loop_step.py 的参数定义--allow-fetch是store_true型布尔参数开启后允许通过 Python 标准库urllib执行 HTTP GET 抓取不带该参数时循环会把需要源抓取的 run 停放起来等待人类处理。这保证了默认路径下守护进程不具备任何网络侧信道网络行为完全由显式开关授权。两个值得注意的行为细节所有脚本都支持--json参数输出结构化结果loop_step会print(json.dumps(result, indent2))便于脚本化消费loop_step在无事可做action no-op时返回退出码78这是正常信号而非错误launchd 包装脚本正是利用这一点与|| true配合实现「无工作时静默跳过」。loop_step.py的模块文档也强调默认--allow-fetch处于关闭状态非白名单的网络调用被禁止——这是安全模型的一部分。人工审查面每天该看哪些文件runbook 建议检查循环状态时阅读以下文件researcher/reports/status.md高层 dashboardresearcher/reports/parked-review.md等待评审人的 run 列表researcher/reports/snapshots/date.md每日快照researcher/reports/benchmark-history.jsonl追加式基准趋势记录researcher/queue/inbox.jsonl等待初始化的候选源researcher/queue/quarantine.jsonl被移出轮换的源。对照 loop_status.py 的实现dashboard 与停放审查面是程序化生成的脚本读取researcher/queue/parked.jsonl与researcher/queue/quarantine.jsonl汇总活跃 run、停放 run、隔离源数量当存在停放记录时把每个 run 的run_id、reason、parked_at渲染进researcher/reports/parked-review.md并输出parked_review_path供 JSON 消费。也就是说这些文件不是手工维护的清单而是循环状态的可读投影。停放 run 的处置动作ReasonActionneeds source retrieval手动抓取证据后执行research_loop.py retrieve --run-dir run --file evidenceneeds evaluation补全源评估 JSON 后执行research_loop.py evaluate --run-dir runneeds human or model action from state proposed完成提案后执行research_loop.py novelty --run-dir runneeds merge approval评审 PR 说明仅在明确批准后合并注意这些子命令都来自 researcher/scripts/research_loop.py是同一研究循环的命令入口与 autonomous-research-loop.md 中定义的init、retrieve、evaluate、novelty、promote-mechanisms等阶段一一对应。安全边界循环绝不越过的红线runbook 明确列出的安全约束均有源码与配置佐证循环从不调用 LLM 或付费 APIconfig.json中mode: dry-rundeep research 与 web search 均关闭抓取只走 stdliburllib抓取限时限量urllib请求带 30 秒超时与 1.5MB 上限防止单次抓取拖垮整个循环失败两次即隔离连续失败的源被移入researcher/queue/quarantine.jsonl退出轮换机制注册表只读机制注册表researcher/mechanisms/registry.jsonl只能通过research_loop.py promote-mechanisms更新且必须有记录的评审人循环本身不编辑它推送与合并始终由人类控制这延续了 autonomous-research-loop.md 的 PR 准备策略——Agent 最多准备 PR 草案合并需显式人类批准。这些约束共同构成了「自动发现、自动起草、人工裁决」的分层信任模型机器负责无风险的推进与记账所有涉及发布、合并、注册表变更的决策都保留给人类。每日节奏值守人员的最小例行流程runbook 给出了一套合理的值守节奏适用于运行该循环的人类操作者早晨阅读最新快照与 parked-review处理停放 run挑最多 3 条停放 run决定推进、拒绝或放弃批准机制提升对已具备发布条件的 run批准其机制提升promote-mechanisms保持循环运行让守护进程继续跑完当天。这套节奏把每日投入压缩到一次短暂检查夜间循环自动完成发现、抓取、评估、起草与校验白天人类只需消化停放队列做裁决。如果需要更细粒度的运行纪律如失败处理矩阵、PR 前置条件、上下文压缩前的手over 清单可进一步阅读同目录下的 autonomous-research-loop.md。排障要点结合源码运行中常见的几个信号与处置建议loop_step以退出码 78 结束属于「无工作」的正常信号不是故障若希望它安静运行保持 launchd 包装脚本中的|| true即可status.md显示 parked 数量持续上升说明有 run 停在了需要人类裁决的节点源抓取、评估、novelty 或合并此时loop_step只会做记账不会继续推进破坏性工作——这符合预算保护语义quarantine.jsonl出现新条目某个源连续失败两次被自动隔离可结合loop_step.log检查失败原因后决定是否重新纳入修改了config.json但调度未生效StartInterval与StartCalendarInterval定义在 launchd plist 中修改后需重新执行 install.sh 让 launchd 重载脚本内部的intervals与 plist 需要保持一致。通过本文所述的安装、预算、审查面与安全模型你可以将这套「自动研究 → 人工裁决」的循环稳定托管在 macOS 上让上下文工程技能的演进在没有人工干预的情况下持续数天推进同时把所有关键决策牢牢握在人类手中。【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考