【交叉评测S1W3】Next Digitwin Ops Copilot Agent #1

New issue

Open

opened 2026-05-25 02:46:45 +08:00 by along429 · 0 comments

along429 commented

2026-05-25 02:46:45 +08:00

项目理解
该项目是面向工业产线设备的运行态数字孪生智能体原型，核心链路：运维人员输入 → 确定性intent路由 → Skill工作流 → 本地数据查询 → AgentResponse/SceneAction输出 → 契约验证 → 6步审计链。目标用户为产线运维工程师、设备工程师、生产管理人员。核心命题是将自然语言请求转化为可控、可信、可审计的数字孪生操作。项目刻意与生产代码隔离，本赛段仅提交前端优先的本地demo。
项目亮点
2.1 Skill契约设计极其规范
8个Skill文件全部包含：Purpose、In/Out Scope、Input/Output Contract（JSON Schema化）、Failure Modes、Evals验收条件。这种"契约先行"的设计在同类项目中属于较高水平。
2.2 "可控AI"与可信机制完善
6步审计链：intent_received → intent_parsed → tool_invoked → retrieval_completed → response_composed → action_executed，在runtime.mjs和skills.mjs中完整实现。
证据引用约束：explain_status要求确定性结论必须绑定point/event/document引用；references为空时强制降级为limited_evidence。
SceneAction后端验证：contracts.mjs实现了9种动作类型的schema验证，包含target存在性校验、style合法性校验、value类型校验。
Live/Replay隔离：replay_review明确声明Live state不可被Replay覆盖，失败时进入replay_error状态。
2.3 工程实现克制且完整
零外部依赖：仅使用Node.js 18+内置能力，符合ESM规范。
评测可自证：eval.mjs包含11个测试用例，覆盖8个Skill + 2个边界用例，每个用例都有明确断言，同时校验response和audit验证结果。
Demo脚本完整：demo.mjs和interactive.mjs的:demo命令覆盖9步交互链路，输出格式统一。
2.4 产品规格承接良好
spec.md（33KB）与本次提交包形成良好承接：FR1~FR6功能需求、SceneAction类型、Audit Step类型、核心Intent、性能目标，在agent.yaml和Skill契约中均有对应映射。
当前不足
3.1 意图解析过于脆弱（核心问题）
skill-router.mjs采用硬编码字符串包含匹配（如query.includes("查看")），而非LLM或正则模式匹配：
"pump_01在哪"可能无法匹配（缺少"查看/定位"关键词）。
"一号泵温度有点高"会被错误路由到query_trend（因为包含"温度"），而非explain_status。
置信度是硬编码固定值（0.90.96），无实际统计意义。
建议：使用更robust的模式匹配（正则、关键词权重、模糊匹配），增加意图冲突检测。
3.2 产线级聚合逻辑深度不足
line_overview的风险等级仅通过some(high/critical)二值判断，没有severity权重累加、recency排序、设备重要性权重。"top risk assets"只是全部高亮，无真正的优先级排序。产线级聚合指标（开动率、平均温度、告警密度）缺失。
建议：补充聚合指标计算，或在Skill契约中降低"top risk ranking"的承诺。
3.3 异常处理存在静默丢弃
skills.mjs的compose函数对invalid SceneAction仅记录到audit，用户侧完全无感知。当设备缺少sceneNode绑定时，用户不知道哪些设备未被高亮。
建议：在answer中增加"以下设备因缺少场景绑定未高亮"的提示。
3.4 fixtures数据过于简化
仅3台设备、4个测点、3条事件（1条resolved）、2条知识引用。count_events的统计意义有限，line_overview难以展示产线级复杂度，无多产线数据。
建议：增加fixtures丰富度（至少2条产线、810台设备、20+事件）。
3.5 explain_status的LLM调用被完全模拟
Skill契约声明"one LLM call is allowed"，但skills.mjs中所有answer都是硬编码模板拼接，无LLM调用。导致回答机械，无法验证"LLM输出schema验证"、retry等Failure Mode的可行性，契约与实现存在落差。
建议：在SUBMISSION.md中明确标注"LLM响应在本demo中由模板模拟"。
3.6 时间范围解析过于简化
仅支持includes("今天")→today、includes("24")→last_24h，无法处理"本周"、"过去7天"等表达。
建议：补充更灵活的时间解析，或缩小契约声明范围。
优先级建议
P0 补充意图解析鲁棒性说明（README/SUBMISSION.md中说明硬编码匹配是demo简化）
P0 补充fixtures数据丰富度（第二产线、更多设备、更多事件severity混合）
P1 增加droppedActions的用户侧反馈（提示哪些设备因验证失败被丢弃）
P1 明确标注LLM模拟状态（避免契约与实现预期落差）
P1 补充audit.mjs源码注释
P2 补充多轮上下文支持的v0.2设计思路
P2 补充npm run eval实际耗时截图/日志
它最大的价值在于认真思考了工业AI如何可控、可信、可审计，而非简单堆砌技术栈。6步审计链、证据引用约束、Limited Evidence降级、SceneAction后端验证——这些设计在工业场景下具有真实落地价值。
当前主要短板是demo阶段的简化程度较高（硬编码意图路由、极简fixtures、模拟LLM），但均在项目边界声明范围内。建议下一轮优先解决：意图解析鲁棒性、fixtures数据丰富度、LLM模拟状态标注。

1. 项目理解该项目是面向工业产线设备的运行态数字孪生智能体原型，核心链路：运维人员输入 → 确定性intent路由 → Skill工作流 → 本地数据查询 → AgentResponse/SceneAction输出 → 契约验证 → 6步审计链。目标用户为产线运维工程师、设备工程师、生产管理人员。核心命题是将自然语言请求转化为可控、可信、可审计的数字孪生操作。项目刻意与生产代码隔离，本赛段仅提交前端优先的本地demo。 2. 项目亮点 2.1 Skill契约设计极其规范 8个Skill文件全部包含：Purpose、In/Out Scope、Input/Output Contract（JSON Schema化）、Failure Modes、Evals验收条件。这种"契约先行"的设计在同类项目中属于较高水平。 2.2 "可控AI"与可信机制完善 6步审计链：intent_received → intent_parsed → tool_invoked → retrieval_completed → response_composed → action_executed，在runtime.mjs和skills.mjs中完整实现。证据引用约束：explain_status要求确定性结论必须绑定point/event/document引用；references为空时强制降级为limited_evidence。 SceneAction后端验证：contracts.mjs实现了9种动作类型的schema验证，包含target存在性校验、style合法性校验、value类型校验。 Live/Replay隔离：replay_review明确声明Live state不可被Replay覆盖，失败时进入replay_error状态。 2.3 工程实现克制且完整零外部依赖：仅使用Node.js 18+内置能力，符合ESM规范。评测可自证：eval.mjs包含11个测试用例，覆盖8个Skill + 2个边界用例，每个用例都有明确断言，同时校验response和audit验证结果。 Demo脚本完整：demo.mjs和interactive.mjs的:demo命令覆盖9步交互链路，输出格式统一。 2.4 产品规格承接良好 spec.md（33KB）与本次提交包形成良好承接：FR1~FR6功能需求、SceneAction类型、Audit Step类型、核心Intent、性能目标，在agent.yaml和Skill契约中均有对应映射。 3. 当前不足 3.1 意图解析过于脆弱（核心问题） skill-router.mjs采用硬编码字符串包含匹配（如query.includes("查看")），而非LLM或正则模式匹配： "pump_01在哪"可能无法匹配（缺少"查看/定位"关键词）。 "一号泵温度有点高"会被错误路由到query_trend（因为包含"温度"），而非explain_status。置信度是硬编码固定值（0.9~0.96），无实际统计意义。建议：使用更robust的模式匹配（正则、关键词权重、模糊匹配），增加意图冲突检测。 3.2 产线级聚合逻辑深度不足 line_overview的风险等级仅通过some(high/critical)二值判断，没有severity权重累加、recency排序、设备重要性权重。"top risk assets"只是全部高亮，无真正的优先级排序。产线级聚合指标（开动率、平均温度、告警密度）缺失。建议：补充聚合指标计算，或在Skill契约中降低"top risk ranking"的承诺。 3.3 异常处理存在静默丢弃 skills.mjs的compose函数对invalid SceneAction仅记录到audit，用户侧完全无感知。当设备缺少sceneNode绑定时，用户不知道哪些设备未被高亮。建议：在answer中增加"以下设备因缺少场景绑定未高亮"的提示。 3.4 fixtures数据过于简化仅3台设备、4个测点、3条事件（1条resolved）、2条知识引用。count_events的统计意义有限，line_overview难以展示产线级复杂度，无多产线数据。建议：增加fixtures丰富度（至少2条产线、8~10台设备、20+事件）。 3.5 explain_status的LLM调用被完全模拟 Skill契约声明"one LLM call is allowed"，但skills.mjs中所有answer都是硬编码模板拼接，无LLM调用。导致回答机械，无法验证"LLM输出schema验证"、retry等Failure Mode的可行性，契约与实现存在落差。建议：在SUBMISSION.md中明确标注"LLM响应在本demo中由模板模拟"。 3.6 时间范围解析过于简化仅支持includes("今天")→today、includes("24")→last_24h，无法处理"本周"、"过去7天"等表达。建议：补充更灵活的时间解析，或缩小契约声明范围。优先级建议 P0 补充意图解析鲁棒性说明（README/SUBMISSION.md中说明硬编码匹配是demo简化） P0 补充fixtures数据丰富度（第二产线、更多设备、更多事件severity混合） P1 增加droppedActions的用户侧反馈（提示哪些设备因验证失败被丢弃） P1 明确标注LLM模拟状态（避免契约与实现预期落差） P1 补充audit.mjs源码注释 P2 补充多轮上下文支持的v0.2设计思路 P2 补充npm run eval实际耗时截图/日志它最大的价值在于认真思考了工业AI如何可控、可信、可审计，而非简单堆砌技术栈。6步审计链、证据引用约束、Limited Evidence降级、SceneAction后端验证——这些设计在工业场景下具有真实落地价值。当前主要短板是demo阶段的简化程度较高（硬编码意图路由、极简fixtures、模拟LLM），但均在项目边界声明范围内。建议下一轮优先解决：意图解析鲁棒性、fixtures数据丰富度、LLM模拟状态标注。

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

JeremyDou/next-manufacture-digitwin-w3#1

No description provided.

Rows
Columns