Article body
正文
客户反馈一份报表的导出结果与页面不一致。Agent 很快找到了导出代码，也给出了修改方案。但研发负责人还需要确认：客户使用什么角色？差异是否来自权限？这次修改会不会影响订阅和嵌入式应用？没有这些依据，生成代码只是任务中的一步。
企业把 Agent 引入研发后，经常在三个环节反复投入：补充项目知识、解释协作流程、检查交付结果。HENGSHI JARVIS 面向这些工作提供咨询赋能方法与实践工具，帮助团队建立知识索引、工作流和质量门禁，让 Agent 能沿着明确的来源与责任边界完成任务。
一、把项目知识组织成可追查的入口
复杂项目的知识散在不同位置：产品文档解释需求，代码记录实现，Issue 留下历史讨论，测试和 CI 证明某次变更的结果。Agent 要判断一个问题，需要知道该去哪里查、哪份材料仍然有效，以及谁能确认业务规则。
JARVIS 的知识索引围绕模块职责、设计决策、已知问题和跨模块关系组织。索引保留来源指针与适用范围，仓库内的 Skills 再说明具体操作和验证方法。例如，“导出结果异常”可以先指向导出与权限模块；若查询上下文由另一个模块产生，就继续沿依赖关系检查交接过程。
这种组织方式也要求团队区分历史、当前事实与待验证判断。JARVIS 的三层时态知识提供了一个理解框架：
| 信息层次 | 在示例任务中查什么 | 使用要求 |
|---|---|---|
| History：历史知识 | 权限设计决策、已知导出问题、模块依赖 | 核对适用版本与后续变更，理解原有约束 |
| Present：当前状态 | 客户角色、配置、目标版本、代码分支与 CI 结果 | 任务执行和继续运行时，回到源系统刷新 |
| Future：候选判断 | 可能的根因、影响范围、修复方案 | 用复现、代码和测试逐项验证，再形成结论 |
例如，历史记录说某类导出曾遗漏权限条件，只能帮助 Agent 确定调查方向。它仍需核对当前请求、身份和代码，才能判断这次是否属于同一问题。团队应为知识指定维护者和更新条件，避免过期经验持续影响新任务。
二、用一个真实触发串起调查、修复和交付
知识准备好之后，还需要明确任务怎样推进。JARVIS 通过工作流与仓库规则组织输入、操作、质量检查和交付要求。Bugfix、功能开发、文档补充可以使用不同的工作规约；具体执行步骤由项目接入的工具、环境和授权决定。
以下以“报表页面与导出结果不一致”为示例，说明一条修复工作流应当留下什么。
1. 固定原始触发
先收集报表、用户角色、查询条件、发生时间和差异样本，并说明预期结果。若页面与导出使用了不同时间范围，先澄清条件；若业务对权限规则存在分歧，先由负责人确认规则。这样，后续测试才能针对同一个问题。
2. 沿数据交接检查影响范围
Agent 根据模块知识定位权限计算、查询执行和导出入口，检查请求在交接时是否保留了身份、过滤条件与指标定义。订阅或嵌入式应用若消费同一份查询结果，也应纳入影响判断。检查哪些关联面，应由共享的状态和调用关系决定。
3. 实施有边界的变更
确认根因后，Agent 在获授权的工作区内修改对应实现，并说明本次允许改变的行为。例如，可以修复导出遗漏的权限条件，同时保留原有角色范围、报表筛选语义和其他用户的结果。涉及产品口径变化时，应交由相应负责人确认。
4. 交付可复核的结果
审阅者应能找到原始触发、代码差异、验证结果和未覆盖条件。仅通过编译，无法证明页面和导出已经一致；应在相同身份、相同筛选条件下检查真实入口。验证环境不可用时，任务记录需要明确失败原因与尚未证明的部分。
图：JARVIS 知识闭环交付流程示意。
三、让任务材料支持中断后的继续执行
多仓库任务可能跨越几次运行，也可能在测试或审阅阶段等待外部条件。接手者需要知道前一次查到了什么、哪些判断已经验证、接下来还缺什么。
在受管执行方案中，团队可分别保留任务目标、每次运行记录、独立工作区和产物，把证据与交接线索对应起来。继续任务时，Agent 仍须刷新会变化的代码、工作项和运行状态。具体的运行环境和记录方式由企业的实施方案与工具链决定。
下面是一份任务交接信息的 YAML 示例，用来说明应记录的内容；它不是 JARVIS 的可直接导入配置格式。
交接信息示例：记录依据、范围与验证结果
task: 报表页面与导出结果不一致
sources:
request: 原始反馈与差异样本
rule: 当前数据权限规则及确认记录
implementation: 本次检查的代码提交
scope:
change: 修复导出链路丢失的权限条件
preserve: 角色授权范围与报表筛选语义
verification:
original_trigger: 相同身份和筛选条件下对比页面与导出
adjacent_behavior: 检查共享查询结果的相关入口
evidence: 实际测试结果与运行记录
unverified: 尚未覆盖的环境或场景
handoff:
reviewer: 对应模块的审阅负责人
next_action: 根据验证证据确认交付状态这类记录让审阅讨论落到具体问题上：结果使用哪份输入，修改解决了什么，哪些风险还有待验证。团队也能据此判断问题出在需求澄清、实现、环境还是测试覆盖，选择后续动作。
四、把一次经验写回适合长期维护的位置
任务结束后，团队需要筛选值得复用的结论。若这次修复揭示了稳定的权限传递规则，可以补充模块决策；若发现两个模块交接时容易遗漏上下文，可以维护跨模块说明；若验证步骤可以复用，可以更新仓库 Skill 或相关测试。
本次账号、临时环境状态和大段运行日志适合保留在任务产物中。长期知识应说明规则、来源、适用范围和维护责任，避免把个案推断当成产品定义。Agent 可以整理候选更新，由对应维护者按现有流程审阅。
反馈也应进入下一轮工作流改进。反复因需求不清而返工，就完善输入要求；经常遗漏同一个消费入口，就补充影响检查；某条测试无法覆盖真实触发，就调整验证方式。这样，团队能用执行证据改进知识和流程。
五、按可验证的成果逐步扩展
JARVIS 的落地可以先选一个高频模块、一类故障或一条文档工作流。首轮交付应包含可用的知识入口、仓库规则、工作流模板、责任人和验收条件，并用实际任务验证它们是否足够清楚。
当单条路径稳定后，再扩展跨仓协作与工具接入，补齐回归测试和审阅机制。后续可跟踪需求澄清往返次数、复现到验证的周期、审阅返工原因和重复问题。比较时需要保持任务类型与验收要求可比，并记录人工接管和环境等待，避免只看生成代码量或模型调用次数。
衡石不同能力在这里各有职责：HENGSHI SENSE 与 Data Agent 服务业务数据分析；HENGSHI CLI 为获授权的 BI 工程操作提供入口；JARVIS 帮助团队组织知识、工作方法与交付责任。企业可按场景组合这些能力，具体接入范围、运行环境和自动化步骤应在实施方案中明确。
团队验收 Agent 工作时，既要看成果，也要能追查依据、检查结果并继续维护。JARVIS 把这些要求落实到知识索引、工作流、运行材料和写回机制中，帮助企业在一次次实际任务中积累可复用的工程能力。