XiaChangSong/BPOS-TMP-REPO
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
113 Commits 1 Branch 0 Tags
e962bb526bd4ab93e5659294b614e2cd288d2fb8
Commit Graph
6 Commits
Author SHA1 Message Date
ChaiHaoandClaude Opus 5 94f31f267b 调优:并发推进的真根因 + loop 的三处行为修正 
E2E 跑 loop 时 A3 一口气发了八张一模一样的「请处理」卡。逐层查下去,四处:

① **并发推进的真根因**:`pg_try_advisory_lock` 是**会话级**的,而我们经连接池取连接 ——
   加锁与解锁多半落在不同连接上,解锁解不掉自己那把;同一连接被复用时又因可重入而直接放行。
   两头都不对,于是同一任务被并发推进(现象:同一步跑两遍、同一张卡发两张、
   同一行草稿写出两条互相打架的版本)。前一轮「共用同一把锁」的修法方向对、器械错。
   改用**进程内按目标互斥**(MVP 单进程,确定且够用),推进器与派发器共用一把;
   多进程部署时再叠事务级 `pg_try_advisory_xact_lock`(随事务释放,不依赖连接归属)。
   实测:同一单从 8 张卡降到 1 张,2 回合后落到等待。

② **非法行动会把回合打死**:AI 提了不合法的生命周期迁移(Available → Disabled),
   `applyAction` 抛出、运行时没落笔、推进器一遍遍重来。引擎拒绝它是对的
   ——「语义忠实:引擎不得私改迁移拓扑」——但不该因此崩掉。
   改为:拒绝 + 留痕 + 把理由喂回下一回合的上下文。AI 提出非法行动是预期内的事。

③ **副作用抢在校验之前**:卡在迁移合法性判定**之前**就发出去了,于是每个被拒的回合
   都白发一张卡 —— 卡收不回,负责人工作台上堆起一摞没人知道怎么答的「请处理」。
   human / tool 两个分支改为**先验迁移再动手**。

④ **裸调用**:模型只回一个「请处理」。按「调用必附上下文,裸调用不得发出」(AM 06)
   把卡面结构写进出参 schema(title / ask / basis / fields 必填),提示里讲明要求,
   归一时用当下局面兜底;卡片装配也修了 —— 结构化 basis 优先,嵌套对象转 JSON,
   不再出现一行 `[object Object]`。
   实测卡面:「请确认 NE555P 历史报价并判定采用策略」+ 三个回填字段。

gates: tsc / eslint / depcruise(336 模块)/ api-report / 429 测试 全绿

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-27 11:31:41 +08:00
ChaiHaoandClaude Opus 5 abd371b51c DeepSeek provider + 判据 ③ 机器路径跑通(零人工兜底) 
Provider 侧:
  · 新增 `provider-profile`(纯数据):各家的默认端点 / 结构化出参姿势 / 是否回推理
    集中一处,adapter 只按画像行事 —— 新增 provider 只改画像,不写一族 if-else。
    DeepSeek:`https://api.deepseek.com`,支持 json_object,v4 系列是推理模型。
  · 建实例时 URL 可留空 → 取该 provider 的默认端点(openai-compatible 本就是
    「随便哪个兼容端点」,没有默认,必须自填)。
  · 推理正文归 `reasoning` 单列:那是**过程**不是结论,不进出参、不参与 schema 校验、
    不入录制(录的是语义入参与结论)。
  · 两档实例 deepseek-v4-flash / deepseek-v4-pro 已建;`quote-extractor` 是**用途名**,
    指向 flash 档 —— 换档只改这一处绑定,活动一行不动。密钥只从环境读、落库即密封,
    治理台只回「是否已绑定」(实测:库里是密文,视图无明文字段,三个实例探活全通)。

沿路修掉五处真问题:

① **同一任务被并发推进**:推进器与派发器各推各的,用的不是同一把锁 ——
   实测同一步跑两遍、同一张卡发两张、同一行草稿写出两条互相打架的版本。
   两者改用同一把 advisory lock(键的推导提取共用)。
② **LLM 步出参从不校验**:声明了 outputSchema,解析不出来就静默当 `{}` 写下去,
   毛病要到下游缺字段时才炸、还炸在别处。改为「出参必过 schema」(AM 12.3),
   不过即按声明的失败走向,并把模型原文记进留痕,好让人看见它到底回了什么。
③ **出参路径不认点号**:入参能走 `a.b.0.c`,出参只认扁平键 ——
   模型按 schema 回嵌套结构(最常见的情形)就写出一条空记录。两边共用一份解析。
④ **归一步拿不到原文**:通道载荷只带指针不带正文、start→A1 边也没把主题正文传下去,
   模型只拿到一个单号,于是回空 records。通道载荷带原文,边映射一路带到 A1。
⑤ **出参形状没讲给模型听**:声明了 schema 却只在提示里写「只输出 JSON」,
   模型只能猜键名(实测回 `{"items":[]}` 而声明要 `{"records":[...]}`)。
   改由网关按 outputSchema 统一附上说明 —— 这是系统的事,不该每个活动作者各写一遍。

另修:连接池没有 error 处理器,空闲连接被服务端掐断会让整个进程退出(一次运维操作
就能把 API 带崩)。

结果:一封 RFQ 入站 → 模型从正文抽出 pn/brand/eau/目标价/交期 →
D1 判定跳过补全 → 查历史价 → DMN 三分类 Type A → 验收放行卡,**全程零人工兜底**。

gates: tsc / eslint / depcruise(319 模块)/ api-report / 409 测试 全绿

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-27 10:25:57 +08:00
ChaiHaoandClaude Opus 5 a9cd6d10c7 M6(2/n): 治理台九功能 + SSE 订阅层 + 读/治分权 
治理台按 §9.1 拆成九个 gov-* feature,共用件落 shared/gov:
  · 外壳(左轨/顶栏/面包屑/页签/整页下钻)自原型 Governance.tsx 平移,
    DOM 与 g-* 类名原样;路由状态即应用状态,区/页签/下钻栈全编码进 hash 可深链
  · 编排画布 diagram-js 画布件 1:1 平移(flow-layout/flow-node-paint/FlowDiagram),
    新增 pkg-to-graph 把 ProcessPackage 转成画布图模型;统一报价 v1 全图 12 节点 15 边渲染通过
  · 后端补四路由:审批单 / 工作流下钻 / 通道实例 / 度量仪表

SSE 订阅层(§9.2):app 层单一连接,按信封目标失效缓存;
组件不再自行轮询(去掉 refetchInterval)。广播只说「哪个目标动了」,不带业务载荷,
且在投递已落库已送达之后才发 —— 不是第二条投递链路。

两处实质修正:
  · 治理路由一律要 govern → 读路由改要 read。客体三类 × 动作三种的分法就是为此:
    BD 有 task:read 能看在途、动不了控制事件;一律 govern 等于把三种动作压成一种
  · 控制事件/恢复/改派原记为 engine-transition(归机器产出)→ 新增 control 条目种类,
    归人裁决侧。归侧是按动作类型的纯推导,所以「谁干的」必须体现在 kind 上;
    否则人的叫停会被算进自主率的机器分子

判据 ⑩ 治理台一半跑通:在途监控 / 叫停 / 恢复,治理动作留痕可查。
无权查看不再画成空清单,按岗位说明缺哪一项。

gates: tsc / eslint / depcruise(286 模块)/ api-report / 360 测试 全绿

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-27 03:28:40 +08:00
JCAI Main AgentandClaude Opus 5 2f01eda3fb M5 收官:六个活动包 + 统一报价全图 + 任务推进器 
活动包(按 MVP示例工作流 归一化):
- quote-intake  A1 受理归一(flow):LLM 抽取 → 条件跳步补全 → 查历史价 → DMN 打标 → 验收
- quote-pricing A4 成本定价(flow):DMN 利润模型 P-01 + 底价门禁 P-02;超限条目调人决策
- quote-negotiate A6 报价议价(flow):写类动作登记意向、放行即落地;建 D+3 跟进监听;
  议价结果建模为选择组三口(成交/有异议/拒绝)—— 业务分支走输出口,不用异常终态编码
- quote-archive A7 情报归档(flow):写共享域(历史价格情报/客户资料库/落地率统计)
- quote-sourcing A3 渠道寻源(loop):CMMN 四阶段 + 里程碑 + 裁量项 + 两个时间监听;
  DMN 采用策略判定;案例说明书与 XML 同版本
- quote-alternative A2 替代选型(loop):CMMN 三阶段 + userEventListener(客户改需求);
  DMN 替代等级判定;禁区「差异没核清的不放行」有机检形态

流程包全图:7 节点 + 3 网关 + 1 审批点
- 已裁定①:A5 = 审批点,G3 并入驳回走向(驳回 → 回 A4 重开新实例)
- 已裁定②:G2 = 并行网关,A3/A2 失败走向 = 容忍
- 已裁定④:议价回环 = 流程层回边(reopen)

闭合校验在此拦下一个真实建模错误(A4 有两条并发入边映射同名字段),
按规范改拓扑:TYPE-A 直通也走汇合;同时把「回边不是并发汇合」写进判定 ——
reopen 边不参与隐式合并检查。

app:task-advancer worker —— 过程在后端,运行中的任务一拍一拍推,不依赖浏览器在线;
进入等待或终结即停手,不空转。第一方工具补齐 P-01/P-02/画像/落地率/出站发送。

已验证(真机):
- 六个活动包经安装通道装入,静态审各 0 条提示
- 流程包闭合校验通过并发布
- 台账自生长:11 张表由活动声明物化(含 shared 三张共享域表)
- 邮件入站 → 触发器 → 工作流 → A1 落到冯兵工位 → 推进器推 2 拍:
  装载 5 步声明 → 执行 LLM 步 → 按声明重试 2 次 → 转人兜底 → awaiting-event
  (LLM 端点是占位 key,失败路径因此走通了 —— 正是声明给定的兜底)

358 个测试通过,门禁五道全绿

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-27 02:37:04 +08:00
JCAI Main AgentandClaude Opus 5 78dc03bb58 app 装配收尾:18 个模块接上,MVP 判据 1-2 端到端跑通 
装配(app 是唯一组装层):
- wiring/engines.ts:skill/flow/loop/task/process/trigger 六个模块经端口接起来;
  两个范式引擎按统一 ParadigmEngine 契约暴露给 task —— 对上层不可区分
- agent-runner.ts:loop 的 Agent 回路经 ModelGateway(两缝之一,回放审看得见);
  出参过 schema 框住三型行动,不合规退化为「等人」而不是乱动世界
- container:interaction / human-tool / activity-registry / release 全部接上;
  event 的 TriggerMatcher 与 org 的 InFlightWorkProbe 以延迟绑定解环,端口不变
- workers/consumers.ts:派发器的两个消费者(任务监听推进旧单 / 触发器开新单,独立判定)
- tools/first-party.ts:查历史价(录制回放替身)+ 三分类打标(纯工具,DMN 确定性求值)
- seed-quote.ts:治理台四件事一次做完 —— 绑 LLM / 注册工具两审 / 经安装通道装活动包 /
  发布流程包(闭合校验通过)+ 配触发器与邮件通道

已验证(真机):
1. 治理台配置全过;活动包静态审 0 条提示、流程包闭合校验通过
2. 一封 RFQ 邮件入站 → 归属解析 → 触发器命中 1 → 起一条工作流 →
   A1 任务按岗位唯一人解析落到 BD 冯兵,runtime=running

修复:zod 判别式重复值(周期触发两型展开为 periodic-calendar / periodic-data,
triggerKindOf 对回三类分类学);活动构建脚本移出 activities(它要用 fs,
而活动包零环境能力 —— depcruise 拦下后按边界搬家)

358 个测试通过,门禁五道全绿

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-27 02:24:36 +08:00
JCAI Main AgentandClaude Opus 5 f0444f1417 M2: 基座能力 —— memory / toolbox / channel / message 
- memory   任务记忆四性质(只追加·信封盖戳·治理先行·归侧)、活动记忆四层与条目三件套、
           任务日志两级投影(结构化零 LLM / 叙述性小结不入事实库)、度量八指标只读投影
- toolbox  注册两审(静态审 + 试运行审)、效应等级决定运行时待遇、契约演进只增不破坏、
           白名单与纯工具私有作用域、ToolInvoker(两缝之二,live/record/replay)
- channel  通道实例配置、入站归一(解析 → 系统写 → 数据事件)、出站发送与关联记录登记
- message  通知 / 跨任务征答(就地作答 · 驳回重答只增不改)/ 死信 / 无主兜底

app:message 接上 event 的 MessageFallback;派发器按目标 ID 取 advisory lock 串行消费 +
消费幂等表;/api/ingest 模拟邮件通道(mock 只在外界)

已验证:无主 RFQ 邮件入站 → 归属解析 no-match → 事件落库 → 兜底落 OP 岗位的消息要素
门禁五道全绿;150 个单元测试 + 1 个 PG 集成测试

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
 2026-07-27 01:16:52 +08:00