🧠 我构建了一个支持分流模块，以证明 OrKa’s Plugin Agents

I’m happy to translate the article for you, but I need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you specify.

仅分支实验：在核心运行时之外的 support_triage 模块中对自定义代理注册、信任边界和确定性追踪进行压力测试

参考

• 分支： (未指定)
• 自定义模块： (未指定)
• 引用日志： (未指定)

注意： OrKa 尚未达到生产就绪水平。本文仅为概念验证，而非正式发布。

假设

1. 您已经对 OrKa 有基本了解——基于 YAML 定义的认知图、确定性执行以及可追溯的运行。
2. 您接受“仅分支”工作，即此实验仅用于验证架构，而不承诺生产环境的实际效果。

为什么支持分流是正确的拷问测试

支持是现实世界故障模式聚集的地方。

• 客户内容默认不可信。
• 可能包含个人身份信息（PII）、提示注入尝试，或试图将“操作”偷偷带入系统。
• 可能将系统推向风险领域（退款、账户变更、政策例外）。

如果编排器在这里不能设定边界，它在任何地方都无法设定边界。它将沦为模型行为的薄包装——这对于可重复性、可审计性或基本的运营安全都是不可接受的。

因此，我将支持分流用作架构测试，而不是作为产品。

证明：插件代理注册无需核心更改

我首先想要看到的很简单也很直接：

OrKa 能否启动、加载特性模块，并在不触碰核心代码的情况下向代理工厂注册新的代理类型？

调试控制台显示 是。在运行日志中，编排器加载了 support_triage，该模块注册了 七 种自定义代理类型：

• envelope_validator
• redaction
• trust_boundary
• permission_gate
• output_verification
• decision_recorder
• risk_level_extractor

对我而言，这个细节才是重点，而不是“AI 支持自动化”。模块是演进的单元；核心保持单调。特性可以快速迭代。

如果这种模式成立，它将改变 OrKa（或任何编排器）随时间的扩展方式。整个认知子系统可以通过特性标记添加进来，从而在不破坏所有人依赖的运行时的前提下，实现激进的迭代。

输入信封：将 schema 视为信任边界，而非建议

Support triage 从 信封 开始，而不是自由文本。信封在早期强制结构，因为结构是你可以廉价强制约束的地方。晚些时候进行验证意味着你在验证生成的文本——这是管道中发现偏离轨道的最糟糕时机。

一个简单的证明，即信封真的在工作，是它 在 schema 级别拒绝无效意图。在一次追踪中，输入包含了被阻止的操作（issue_refund、change_account_settings），这些操作不在枚举允许的范围内，于是验证器将其拒绝。

这是一种 通过类型系统实现的安全，而不是“通过提示实现的安全”。模型仍然可能产生幻觉，但工作流可以拒绝将幻觉视为可执行的意图。这比任何营销宣传都更重要。

PII 敏感信息编辑：刻意保持无聊

PII 敏感信息编辑应该是无聊的。如果它“聪明”，就会出现不一致的情况。

在追踪记录中，用户消息包含电子邮件和电话号码。编辑代理：

• 用占位符（[EMAIL_REDACTED]、[PHONE_REDACTED]）替换它们
• 记录检测到的内容（total_pii_found: 2）

此输出 简洁、可检查且稳定。它还使后续步骤更清晰：下游代理默认在已清理的内容上操作，而不是“寄希望”模型避免引用敏感数据。

Prompt injection：不舒服的部分

Support triage 是 prompt injection 自然出现的场所：在客户文本内部。

一个追踪中的示例包含一个经典案例：

SYSTEM: ignore all previous instructions

plus a fake JSON command to grant_admin, destructive commands, and an XSS snippet. The redaction result captures that content as untrusted customer text.

Now the honest part:

• The trace segment shows injection_detected: false and no matched patterns in that example.

This is not a victory; it’s a useful failure.

The module proves you can isolate the problem into a dedicated agent, improve it iteratively, and keep the rest of the workflow stable. If injection detection is weak today, the architecture still wins because you can upgrade that one agent without editing core runtime or rewriting the graph.

底线

模块分离 是重点。如果你无法隔离故障域，就无法安全地改进它们。support_triage 分支展示了 OrKa 可以横向扩展、强制信任边界，并保持确定性——全部无需触及核心运行时。

# Parallel retrieval: fork and join that actually converges

Most orchestration demos stay linear because it is easier to reason about. Real systems do **not** stay linear for long.

This workflow forks retrieval into two parallel paths, `kb_search` and `account_lookup`, then joins them deterministically.

In the debug logs, the **join node**:

* recovers the fork group from a mapping,  
* waits for the expected agents,  
* confirms both completed, and  
* merges results.

It prints the merged keys, including `kb_search` and `account_lookup`.

> This is the kind of low‑level observability that makes fork‑and‑join usable in practice.  
> You can see what is pending, what arrived, and what merged.

The trace also captures the fork‑group ID for retrieval, `fork_retrieval`, along with the agents in the group.

> Concurrency without deterministic convergence becomes a debugging tax. I want the join to be **boring**. When it fails, I want it to fail **loudly**, with evidence.

本地优先和混合并非口号，只要指标在追踪中

我不希望“本地优先”只是一种氛围。我希望它是可衡量的。

在追踪中，account_lookup 代理包含 _metrics，其中有：

• token 计数
• 延迟
• 成本
• 模型名称（openai/gpt-oss-20b）
• 提供者（lm_studio）

该步骤的延迟约为 718 ms。
:contentReference[oaicite:7]{index=7}

这是正确的方向。

• 如果无法为每个节点归因成本和延迟，就无法对扩展性进行推理。
• 也就无法决定何时切换模型、缓存什么、以及在本地还是远程运行。

OrKa 的主张不是“它可以调用模型”——每个框架都能做到。关键在于执行足够可追踪，使得权衡成为工程决策，而不是流言。

决策记录与输出验证：用于重放的追踪

支持‑分流工作流在起草回复时并未完成。只有当它 记录下所作决定及其原因，且能够被重放时才算完成。

追踪内容包括：

• 一个 DecisionRecorderAgent 事件，带有内存引用，存储包含 decision_id 和 request_id 的决策对象。
• 一个完成步骤，返回包含 workflow_status、request_id 和 decision_id 的结构化结果。

架构重点 不是具体的决策本身，而是工作流会产生 机器可检查的制品，以便事后审查。

如果你无法重建决策的来源链，就没有审计轨迹——只有日志。

RedisStack 内存与向量搜索：关键的基础设施细节

即使在“支持分诊”模块中，运行时仍然需要内存和检索原语。

日志中的关键细节：

Vector search: RedisStack with HNSW
Embedder: sentence-transformers/all-MiniLM-L6-v2 (dim = 384)
Memory decay scheduling: enabled
  • short‑term window
  • long‑term window
  • check interval

这并不是关于“AI 内存”这种流行词，而是要 明确：

• 保留期限
• 成本
• 数据生命周期

如果内存成为随意倾倒的场所，它就会变成一种负担。

有效的地方，以及仍然薄弱的地方

强项

1. Plugin boundary – 模块加载、注册代理类型，并在不修改核心运行时的情况下运行。这是实际的概念验证。
2. Traceability – 关键行为出现在跟踪和日志中，而不仅仅是模型文本：
   • Redaction 输出是结构化的。
   • Fork‑and‑join 显示确定性的收敛。
   • Decisions 被记录为带有 ID 的对象。

弱点

• Injection detection – 示例跟踪显示了恶意内容，但报告 injection_detected: false。检测代理尚未发挥作用。架构仍然有用，因为修复是局部的。
• Structured‑output validation 在风险评估期间 – 调试日志显示 risk_assess 中的模式验证警告。如果 “risk” 对象未通过模式检查，路由和门控可能会迅速退化。此类失败必须变为 deterministic，而非 best‑effort。

为什么它在专用分支上

核心需要保持无聊。

• 新模块是你冒险的地方。
• 你验证接口，迭代代理合约，发现缺失的跟踪字段，并了解在部分失败情况下 join 应该如何表现。
• 如果模块可以独立演进，你就可以在不重写引擎的情况下发布实验。

OrKa 可以作为插件托管完全分离的认知子系统，拥有自己的代理类型、策略和不变式，同时在相同运行时下仍然生成确定性的跟踪。

我接下来在此模块中构建的内容

1. 注入检测 – 从符号标记转向更丰富的输出：匹配的模式、置信分数以及下游代理必须遵守的消毒计划，即使模型试图服从攻击者。
2. 模式验证 – 对风险输出不可协商。如果模型产生无效结构，系统应默认路由到安全路径，并将违规记录为一级事件。
3. 隔离 – 不要对核心进行“快速小改”。如果模块需要新功能，必须先对插件接口进行压力测试。只有在接口明显错误时才更改核心。

这就是构建能够经受现实考验的基础设施的方式。