Spindrift の车厢

这几天在围绕一个HRMS(人力资源管理系统)做Agent。开发周期只有一周。大概是想实现这几个亮点吧。

Agent亮点

🌟 亮点一：个性化数据感知 (Personalized Context-Awareness)

设计思路：打破静态文档库的限制。Java 授权上下文服务只向 Agent 提供经过 DataScope 校验的最小化业务事实（如工龄区间、可用假期余额、所属部门），不直接传输完整员工档案或敏感字段。AI 助理在解答政策时，能针对该员工的特征进行“实时算账”。
业务价值：免去员工自行查表算工龄、算天数的痛苦，提供温暖的人性化问答。

🌟 亮点二：智能表单参数预填 (Smart Form Parameter Auto-filling)

设计思路：利用大模型实体槽位填充（Slot Filling）技术，识别对话中的业务参数（如请假类型=年假、开始时间=下周一、时长=1天、原因=旅游），生成待确认的业务草稿。Java 创建绑定当前用户、动作类型和过期时间的一次性 draftId，前端凭 draftId 拉取草稿，不在 URL 中传递敏感表单字段。
业务价值：用户点击跳转后，页面表单已自动填妥，员工先核对草稿，再点击正式提交。实现“一句话生成申请草稿”，同时保留人工确认和审计边界。

🌟 亮点三：引导式“快捷追问”气泡 (Contextual Suggestion Chips)

设计思路：根据对话的上下文和意图，动态预测并生成 2-3 个相关的后续关联问题，以胶囊气泡形式展现在消息框底部。
业务价值：降低输入成本，引导用户探索系统能力，防止“不知道问什么”的尴尬。

🌟 亮点四：可视化流程图与时间线渲染 (Visual Workflow Renderer)

设计思路：将流程繁琐、涉及多个阶段的制度（如离职手续、入职报到、调岗转正），在聊天框内直接渲染成精美的垂直步骤条（Steps），并在步骤中直接嵌入动作入口。
业务价值：把密密麻麻的条目文字转为高可视化的进度轴，阅读体验倍增。

🌟 亮点五：主动式关怀与事件推送 (Proactive Notifications)

设计思路：系统不仅是“被动的回复者”，也是“主动的主管”。通过监听后台消息队列（RabbitMQ）中的业务事件，当扫描到员工重要节点（如转正期将满、超时待批流程、生日关怀）时，在前端侧边栏或微信端主动发起会话。通知必须支持用户订阅、安静时间、频率限制和去重，敏感内容不直接推送。
业务价值：将 AI 助理打造成系统级的“主动通知中心”与“小助手关怀前哨”，但不打扰用户，也不借通知绕过权限。

🌟 亮点六：微信 (Hermes Agent) 文本联动通道

设计思路：利用已部署的 Hermes Agent 微信网关，将网页端 AI 能力无缝延展到移动端。员工在微信发送文字消息，Hermes 转发给 Python 代理服务进行问答检索与意图路由，并将文本解答与操作卡片发回微信。
业务价值：打通移动办公，让出差人员在微信中通过纯文字交互即可查询制度和办理报销、请假，体验极轻，且不产生任何语音接口的额外开销。

🌟 亮点七：政策来源与有效期卡片 (Policy Citation Card)

设计思路：每条政策回答都附带结构化来源卡片，展示制度名称、版本号、生效日期和适用范围；回答正文只引用经过授权的政策内容，不展示内部文件路径或敏感原文。
业务价值：让员工知道“答案从哪里来、是否仍然有效”，提升 HR 场景下的可信度和可追溯性，也方便 HR 发现制度过期或知识库缺口。

🌟 亮点八：草稿而非直接执行 (Draft-Then-Confirm)

设计思路：所有涉及业务变更的请求统一经过“识别意图 → 生成草稿 → 用户确认 → 正式提交”的状态机。AI 可以辅助填写，但不能仅凭自然语言直接提交请假、调薪、离职或审批动作。
业务价值：在减少输入成本的同时，保留用户最后确认权，降低日期、金额、对象识别错误造成的业务风险。

🌟 亮点九：可追踪的操作回执卡片 (Action Receipt)

设计思路：业务提交成功后，Agent 返回标准化回执卡片，包含申请编号、当前状态、提交时间、下一步责任人和详情入口；失败时返回原因与可恢复操作，不只显示“操作成功”。
业务价值：把对话从“给建议”延伸到“闭环办事”，让员工能确认申请是否真正进入审批流，也便于后续追踪和审计。

🌟 亮点十：AI 质量评测与安全观测面板 (Agent Evaluation Console)

设计思路：为 HR/管理员提供内部评测面板，基于固定问题集和真实脱敏样本，统计意图识别准确率、政策引用正确率、越权拒答率、路由正确率、用户确认率、平均响应时延和模型失败率。
业务价值：把“AI 看起来很聪明”变成可以持续验证和迭代的工程指标，支持模型、Prompt、知识库和权限策略的回归测试。

造出那个核弹的提示词

然后你猜怎么着？我就把初步的包含亮点的设计稿发给了GPT 5.6 Sol大人

你是一个企业级 HRMS Agent 架构审核师和技术选型评审师。

请基于我提供的当前代码、OpenSpec 和设计文档，对 HRMS Agent 做一次全局架构梳理和技术栈评估，生成一份总系统分析设计文档。
### Agent 当前已实现状态（FACT）
- Python Agent：FastAPI 服务，纯关键词匹配，3 个策略文件
- 无 LLM、无 Embedding、无向量数据库、无 Reranker
- Java 代理层：完整的 SSE 转发、ContentGuard、会话存储（Redis）、
  路由目录、来源目录
- 协议：Chat Protocol v1 已稳定
- 前端：聊天侧边栏 UI 已集成在 BasicLayout

### 升级设计方案（PROPOSED，尚未实现）
- agent/2026-07-10-hrms-ai-assistant-design-upgrade.md 提出了
  10 个亮点功能，包括 LLM 接入、RAG、个性化上下文、草稿预填等
- 这些均为设计文档提出的未来能力，当前代码未实现

## 最少包含以下模块，你可以添加额外模块

# 一、（最重要）Agent 开发模块拆分+模块依赖关系
1. 每个拆分出的 Change 可以是高内聚、低耦合。主要是去拆分成openspec的每一个change,让我们的开发人员去根据change进行分阶段的开发
2. 可以给出 Mermaid 或 ASCII 依赖图。
3. 标明每个阶段的产物

# 二、Java、Python、前端之间的信任边界

说明：

1. 哪些请求只能经过 Java
2. Python 能接收哪些数据
3. Python 不能接收哪些数据
4. 哪些数据只能由 Java 生成
5. 哪些字段必须由 Java 校验
6. 哪些内容不能由 LLM 决定
7. 浏览器、Java、Python、Redis、向量数据库各自的信任级别

特别检查：

- Token 是否可能进入 Python
- Python 是否可能返回任意 URL
- LLM 是否可能直接执行 HRMS 业务动作
- 敏感字段是否可能进入 Prompt、Redis、日志或向量库

# 三、数据流与敏感数据流向

分别描述：

1. 普通政策问答
2. RAG 检索
3. 未来意图识别
4. 未来业务路由
5. 未来个性化数据查询

# 四、协议和接口稳定性

评估当前 `agent/chat-protocol-v1.md` 协议对于未来 LLM/RAG/Tool Use 扩展的支持力度，指出是否需要增加新的控制指令

# 五、技术栈确认与选型


重点评估：
## 1. Reranker 有没有必要
## 2. RAG 框架
我们想用
- LangChain+LangGraph
有没有必要用DeepAgents?
## 3.向量数据库
## 4. 会话存储
支持多轮会话吗？有没有必要储存会话给用户？

## 6. 监控与审计

评估是否需要：

- 请求日志
- 检索日志
- 模型调用日志
- Token 使用统计
- 延迟统计
- 错误统计
- 敏感数据审计
- Prompt/回答留存策略

# 六、安全与可用性风险矩阵
重点：
1. Prompt Injection
2. 敏感字段泄露
3. 员工数据跨用户访问
4. 任意 URL 跳转
5. 任意工具调用
6. LLM 幻觉
7. RAG 错误召回
8. 权限标签失效
9. Redis 历史污染
10. SSE 中断
11. Python 服务不可用
12. 向量库不可用
13. 模型供应商不可用
14. 数据库和索引不一致
15. 日志泄露敏感内容
16. 模型供应商锁定
[省略]

AI反馈

然后理所当然的，GPT 5.6 sol大人给出了他的设计文档。以下是changes 节选至总系分设计文档

ID / Change 名	高内聚范围	明确不包含	依赖	阶段产物
C0 `harden-agent-trust-boundary`	Java↔Python 服务认证、网络策略、DLP、请求/响应限额、conversationId 格式、真实超时、专用线程池、限流、取消、secret 清理	LLM、RAG、UI 新功能	现有 foundation	安全规格、威胁模型、加固实现、攻击/超时/并发测试、密钥轮换说明
C1 `add-agent-observability-evaluation-foundation`	trace/request id、指标、结构化脱敏日志、审计事件、离线评测数据格式与基线	管理面板、RAG 功能	C0	指标字典、审计 schema、固定评测集、基线报告、留存策略
C2 `add-agent-model-gateway`	LangChain 模型适配、供应商配置、结构化输出、超时/重试/熔断、token/cost 统计、关键词降级	向量检索、业务工具	C0、C1	Provider 接口、首个模型实现、Prompt 版本库、mock/契约测试、降级演练
C3 `add-agent-knowledge-lifecycle`	政策 schema、分块、版本/有效期/适用范围、Embedding、Qdrant、增量入库、重建/快照	在线回答生成、员工数据	C0、C1	语料准入规范、索引 manifest、入库 CLI/job、Qdrant 配置、备份恢复手册
C4 `upgrade-agent-chat-protocol-v2`	v2 版本协商、控制事件、Schema、兼容性和 conformance tests	具体 RAG/草稿业务实现	C0	v2 协议、Java/Python/TS 类型、状态机、兼容测试工具
C5 `add-agent-rag-policy-qa`	受控检索、hybrid、引用、grounded answer、Prompt Injection 防护、无答案拒答	个性化员工数据、动作	C2、C3、C4	RAG graph、引用链、Golden Set 结果、召回/忠实度/延迟门槛、降级到关键词
C6 `add-agent-intent-safe-routing`	LLM 意图分类、置信度、逻辑 routeKey、Java 目录校验、澄清/拒绝	槽位草稿、业务提交	C2、C4	意图目录、JSON Schema、混淆集、路由准确率报告、回退规则
C7 `add-agent-structured-chat-ui`	citation、suggestion、steps、status 卡片的前端白名单 Renderer 与无障碍体验	draft/receipt 的业务状态机	C4、C5、C6	Renderer 注册表、前端组件、降级文本、协议兼容/UI 测试
C8 `add-agent-authorized-context`	Java 最小化上下文网关、DataScope/字段级校验、只读事实 schema、用途限制	工资明细等高敏字段、写动作	C0、C2、相关领域规格就绪	Context API、事实白名单、授权矩阵、越权测试、字段泄露评测
C9 `add-agent-business-drafts`	槽位候选、Java 重新校验、一次性 draftId、TTL、用户绑定、预填拉取	正式业务提交	C6、C8、目标领域表单规格	Draft 状态机、MySQL 迁移、草稿 API、页面预填、过期/重放测试
C10 `add-agent-confirmed-actions-receipts`	明示确认、再次授权、幂等提交、领域服务调用、标准回执	模型自动审批/自动提交	C9、目标领域服务/审批规格	Confirmation API、幂等键、审计链、receipt schema、端到端测试
C11 `add-agent-reranking`（条件 Change）	候选重排、模型/服务适配、延迟预算、A/B 评测	首期必选依赖	C5 且评测触发	Reranker adapter、对照报告、阈值、开关和回滚
C12 `add-agent-evaluation-console`	管理员查看质量、成本、安全和版本趋势	原始敏感对话浏览器	C1、C5、C6	管理 API、脱敏聚合表、面板、RBAC 与审计
C13 `add-agent-proactive-notifications`	RabbitMQ 事件、订阅/静默时间/频控/去重、非敏感通知	微信通道、无确认动作	C1、C4、相关领域事件	通知策略、事件消费者、去重键、用户设置、压测
C14 `add-agent-hermes-channel`	外部身份绑定、Java 渠道网关、消息签名、防重放、渠道能力降级	Hermes 直连 Python、敏感明文推送	C0、C4、C6；动作需 C10	渠道协议、绑定流程、签名验证、风控/审计、端到端演练

我的发现

okok 这么强大？终于能做出来企业级而不是demo级的Agent了吗？

做完第一个change:

Java跟python服务通信要用到HMAC + keyId + 时间戳 + nonce + 防重放缓存？高级！

哇塞java这边开了专用线程池 + semaphore + watchdog + 生命周期状态机 + Redis 分布式限流 + 用户 lease？高级！

安全规格、威胁模型、加固实现、攻击/超时/并发测试、密钥轮换说明。额，高级。！

做完第二个change：

python这边怎么已经上千行代码了？我还看不懂？还没有一点业务逻辑...

自定义指标字典、标签基数保护结构化脱敏日志、审计事件、离线评测数据格式与基线

做完第三个change:

超时..重试...熔断...等等怎么做了这么多连一点业务核心都没写？全是python原生代码根本看不懂听说有个langsmith 也没时间研究了

我的动作

灰头土脸的花了一吨token，做了一堆东西，然后发现太复杂了被迫重构返工

只能让AI重构原设计方案了。

摘自重构后的设计方案..................哎

HRMS Agent 定位为面向课程项目的学习型业务 Agent。项目优先完成用户可感知的核心功能，并重点学习：

Hybrid RAG、引用与无答案拒答；
真实短期多轮对话；
意图识别与轻量 LangGraph 编排；
Tool Calling 与 Java 权限边界；
草稿、人工确认、幂等提交和业务回执；
跨 Java、Python、TypeScript 的结构化协议；
小型离线 AI 质量评测。
系统不以建设企业级 AI 平台为目标。监控、审计、安全、容灾和知识运维只保留支持上述功能所需的最低边界，不再成为独立平台或后续功能的前置负担。

经验教训

总设计文档真的是一个很重要的东西，我是用openspec框架做SDD开发的，一切changes源于总系分。

所以不管再懒，都要把总系分研究的彻彻底底，跟ai互相拷打，给整透彻。而不是直接拿changes去开发。

然后感觉AI带来的高级感是非常危险的，这种高级感就体现在AI说了一堆高级名词，但是你看不懂感觉交给AI去做就行了，这都是对的。很容易会带来预期之外的结果，之后就是越走越偏。。

然后就是开发项目要开排期吧。这次agent只有一周时间开发，审计还有好多校验安全性什么的我从没接触过的领域，是真没空去研究了，让AI全生成也不放心，只能被迫放弃了。