LingCoreX.AI 正在规划一层位于上游模型执行之前的插件能力，用来在不改变 OpenAI 兼容接入方式的前提下，对请求做更细粒度的控制，例如 prompt 压缩、敏感数据遮盖以及后续的请求治理。
插件层面向那些希望在请求进入模型之前增加控制能力的团队，例如减少无效 token 消耗、限制敏感信息外发，以及在不改应用侧调用方式的情况下加入统一治理策略。
运行位置
请求前
插件的目标是在最终 payload 发往上游模型之前执行。
核心目标
更可控
减少无效 token 开销，并降低敏感信息误发给 LLM 的风险。
当前状态
部分已上线
本页介绍的是规划能力，不应视为已经正式上线的 GA 功能。
在尽量不引入推理偏移的前提下压缩长 prompt。
Token Compressor 面向包含大量重复策略文本、冗长对话历史、重复指令或超长检索片段的请求，目标是在降低 token 消耗、提升上下文装载效率的同时，尽量保留任务真正需要的语义和推理线索。
Use cases
长时间运行的 Agent 会话，历史上下文中积累了大量重复规划文本。
RAG 工作流里检索内容有价值，但原始片段过长。
企业级 prompt 每次都附带大量固定治理规则和模板。
Guardrails
保持推理稳定性是设计目标，但不能对所有 prompt 形式做绝对保证。
高风险业务在生产启用前，仍应对原始请求和压缩请求做效果对比。
建议支持自动、规则式和人工确认等不同压缩模式，以便逐步上线。
概念示例
原始请求
SYSTEM: Follow the company policy below... [2,000 tokens of repeated governance text] USER: Summarize the latest incident report and propose three next actions.
压缩后请求
SYSTEM: Apply the approved governance rules, privacy posture, and escalation policy from profile A. USER: Summarize the latest incident report and propose three next actions.
在请求发往模型之前，对密码、密钥和个人标识做预遮盖。
隐私遮盖器面向希望增加预发送清洗环节的团队。它会在请求转发给上游模型前，扫描可能出现的密码、API Key、私有标识、联系方式或内部凭据，并用 [Password]、[APIKEY]、[Personal ID] 等稳定占位符替换原值。
Use cases
客服人员粘贴用户故障信息，其中可能包含凭据或个人标识。
工程类 prompt 附带了日志、配置文件或部署输出，内部含有密钥。
多租户场景下，希望内部 ID 不以明文形式离开组织边界。
Guardrails
遮盖能降低误泄露风险，但不能替代完整的数据分级和合规体系。
团队仍需要定义哪些信息在任何情况下都不应发给第三方模型。
基于规则的遮盖能力应结合真实数据格式持续校验误判和漏判。
概念示例
原始 payload
User says their password is hunter2, API key sk-live-abc123, and Personal ID CN-556677 before requesting account recovery guidance.
遮盖后 payload
User says their password is [Password], API key [APIKEY], and Personal ID [Personal ID] before requesting account recovery guidance.
把团队的所有 LLM 交互存储到自有存储桶，支持合规审查与内容分析。
团队消息审计插件将每次 LLM 请求和返回的完整 payload 写入团队自己配置的 S3 存储桶或阿里云 OSS。由于 LingCoreX 本身不保存用户消息数据，需要留存对话记录用于合规审计或内容审查的团队可开启此插件，将原始日志持久化到自有存储。内置审计工具支持授权管理员查看团队成员的 user prompt 内容、查看原始请求日志，以及按成员进行多维度分析。每次审计请求消耗 1 credit。
Use cases
需要留存完整 LLM 交互记录、满足内部或监管合规要求的团队。
希望确认没有敏感信息通过 prompt 外泄的安全审查场景。
需要了解成员向模型发送了哪些 prompt 内容的团队管理者。
Guardrails
存储桶由团队自行配置和管理，LingCoreX 只负责写入日志 payload，不具备读取权限。
如果目标存储桶在请求时不可访问，团队需提前定义回退策略：阻断请求还是直接放行但跳过日志写入。
审计工具的访问权限应严格控制在授权管理员范围内，避免团队成员 prompt 内容被意外暴露。
工作原理
未开启插件
请求被转发至上游模型，返回结果给调用方，LingCoreX 不存储任何消息内容。
开启团队消息审计后
在返回给调用方之前，请求和返回的完整 payload 会被写入团队配置的 S3/OSS 存储桶。管理员随后可通过审计工具按成员查看 prompt 内容及原始请求日志。
在 Token 压缩之后，插件层还可以继续承载更多请求治理能力，而不需要改变应用侧的调用协议。