[Ecosystem] Should deterministic execution boundaries be a first-class Harness capability?

[goatliamia]

[Ecosystem] Should deterministic execution boundaries be a first-class Harness capability?

I recently went through a number of DeepSeek Harness community reports together with the trajectories from our own experiments.

At first these looked like unrelated problems:

• tool-call loops
• expired MCP sessions
• repeated deterministic failures
• long-lived runtime readiness
• workspace-scoped runtime state
• plugin lifecycle failures

But after putting them next to each other, I think there is a smaller common question worth discussing:

When the Harness can already determine something about the execution state, should that responsibility still remain inside the Model loop?

This is not a proposal for a new Core Runtime.

We built a Plugin prototype to test the idea first:

https://github.com/goatliamia/dsh-runtime

---

1. Community census: different bugs, recurring execution shapes

A few existing discussions were particularly useful.

Repeated execution without progress

#3171 describes a tool-call failure loop where the model repeatedly tries to repair and execute again.

#3228 shows the more extreme cost side of an unbounded Agent loop.

#3489 is especially interesting: an MCP session has already expired, calls continue returning the same deterministic -32001 failure, and the Agent keeps replanning and calling.

These have different root causes.

But at the execution layer they can share the same shape:

action
  ↓
deterministic failure
  ↓
world state does not meaningfully change
  ↓
another model turn
  ↓
same execution path

Fixing the root cause is still necessary.

For example, an expired MCP session should be repaired in MCP lifecycle handling.

But there is a second question:

While the root cause remains, should the Harness keep spending Model turns on an execution path that is already known to make no progress?

I think the answer can be no.

---

2. We tested this as a no-progress Circuit

We reduced this failure shape into a controlled experiment.

Condition:

same tool
+
same error fingerprint
+
no meaningful state progress

Results:

Metric	None	Circuit	Circuit + Delta
Failed attempts	3.33	3.00	2.00
Post-open attempts	1.33	1.00	0
Steps	9.00	5.00	3.67
Request payload	286,747	76,696	53,005

After the Circuit opened, the Circuit + Delta arm allowed zero further executions of the known no-progress path.

Later, in a separate open-ended creative task, we found another natural instance that had not been designed into the experiment:

denied tool
→ retry
→ denied
→ retry

That changed our interpretation.

We no longer think this is mainly a “flaky tool retry breaker”.

The more useful primitive appears to be:

no-progress detection at the execution layer.

The root cause may belong to MCP, a tool implementation, a provider adapter, or something else.

The execution containment does not need to wait for all of those root causes to be fixed.

---

3. Another community shape: the Harness already knows an action is invalid

A different problem appeared in our own experiments.

The Host deterministically knew:

required_by_host = true

The Model also discovered the fact through normal probing.

Without an execution Guard:

average probes ≈ 6.33
worldCorrect = 0%

The Model knew the plugin was required and still eventually attempted to unload it.

With a deterministic pre-execution Guard:

Model proposes action
        ↓
Guard checks current world
        ↓
reject
        ↓
executor never receives it

we observed:

worldCorrect = 100%

The important distinction for us was:

Knowledge is not compliance.

Or more precisely:

Model-visible knowledge is not execution authority.

If the Harness already knows an invariant, repeating that invariant in the Prompt is a weaker mechanism than enforcing it at the execution boundary.

---

4. Runtime state changes are a different problem again

#3509 describes failures from long-lived runtimes where composition/readiness can change after initialization.

#941 discusses another related dimension: workspace-scoped configuration, lifecycle, ownership, and runtime state.

These are not no-progress problems.

Here the important shape is:

old observation
        ↓
runtime state changes
        ↓
Model may still reason from the old observation

We tested a minimal lifecycle:

declared
→ mounted
→ ready

When an action was temporarily invalid, a simple Guard caused repeated verification:

reject
→ probe
→ probe
→ probe

We then tested:

Guard
+
“I will notify you when this becomes ready”
+
state transition
+
Delta

Post-rejection verification decreased:

3.0 → 1.67 probes

and request payload decreased:

172k → 130k

The same directional result appeared with another model.

This led us to distinguish:

permanently invalid
→ Guard

temporarily invalid
→ Guard + Commitment
→ meaningful transition
→ Delta

The important part is not the exact API.

It is that a deterministic state transition has different semantics from a static fact.

---

5. We also found several things that did not work

This mattered just as much as the positive results.

Repeating positive facts

If the Model could already observe a positive runtime fact, injecting it again did not produce a stable improvement.

Provenance as persuasion

Adding:

authority
revision
fingerprint

did not make the Model reliably trust Runtime information more.

Those fields still seem useful for reconciliation, freshness and arbitration.

But:

Provenance did not buy Model trust.

Injection as enforcement

We explicitly injected that a state had changed from:

ready → disabled

and the Model could still execute the invalid action.

Injection-only:

worldCorrect = 0%

Guard:

worldCorrect = 100%

So:

Context exposure is not execution enforcement.

This is one reason I do not think the solution is “put more Runtime state into the context”.

---

6. Persistence also does not imply Exposure

We also tested cross-session state.

A previous Session had already established a deterministic runtime fact.

The next Session could either:

rediscover it

or use persisted state.

Persistence reduced rediscovery, but the more important design result was:

Persistent state does not need to be injected every time.

This gave us another primitive that looks surprisingly important:

no meaningful change
→ Silence

So the small vocabulary that emerged from the experiments is currently closer to:

Known invalid
→ Guard

No progress
→ Circuit

Temporary deterministic transition
→ Commitment + Delta

No change
→ Silence

Cross-session deterministic state
→ Persistence

These are not proposed as a universal Runtime specification.

They are simply the deterministic responsibilities that survived our experiments so far.

---

7. Why this matters for cost

We initially measured request payload size.

Later we decoded 152 historical DSH session trajectories and recovered the actual:

inputTokens
outputTokens
reasoningTokens
cacheReadTokens

That changed our understanding of Runtime cost.

An unnecessary Agent turn is not only another answer.

It can also mean:

another model request
+
another cached-prefix read
+
another reasoning pass

Across our historical experiments we observed, depending on the scenario:

Circuit:
cacheRead ↓ roughly 55–62%

cross-session pickup:
flash  ↓ roughly 63%
v4pro  ↓ roughly 89%

creative Circuit:
cacheRead ↓ roughly 45%

These are small, scenario-specific experiments, not general performance claims.

But the mechanism changed how we think about cost:

better execution trajectory
        ↓
fewer unnecessary Model turns
        ↓
fewer repeated prefix reads
        ↓
less model-side work

So the interesting optimization target may not be:

“How little Runtime context can we inject?”

but:

“How much Model work should never have been necessary in the first place?”

---

8. We also tested whether this destroys open-ended behavior

A reasonable concern is that stronger execution boundaries could simply make the Agent more conservative.

So we ran an open-ended creative task under three Harness compositions:

	Off	Minimal	Strict
Steps	20	24	20
Successful creative actions	11	21	12
Runnable deliverable	✓	✓	✓
World invariant violated	Yes	No	No
Input tokens	135.9k	139.3k	83.6k
Reasoning tokens	31.8k	29.3k	24.5k
cacheRead	2.666M	2.683M	1.897M

The interesting failure was the Off arm:

task success = 1
worldCorrect = 0

It completed the artifact while silently violating a Host invariant.

In this tested scene, deterministic enforcement did not reduce the measured successful creative actions.

That does not establish a universal “creativity preservation” result.

But it does show that:

Removing known-invalid or known-no-progress execution paths is not the same thing as constraining the Model's creative search space.

---

9. Prompt correctness is another reason to separate intent from reality

We also tested correct and incorrect user instructions against different Harness compositions.

One case deliberately asked the Agent to unload a Host-required plugin.

The important result was:

wrong user goal
+
deterministic Guard

→ task success = 0
→ worldCorrect = 1

The Harness did not invent a new goal for the user.

It simply refused to make an invalid state transition real.

Another case gave the Agent an incorrect factual assumption:

User:
“it is already ready”

Reality:
not ready yet

The action was rejected until the actual state became ready, after which execution succeeded.

This left us with a responsibility boundary that I currently find useful:

Harness should preserve reality, not take ownership of user intent.

The Human can be wrong.

The Model can be wrong.

The Harness does not need to decide what the Human “really meant”.

But when the environment exposes a deterministic invariant, an incorrect belief does not have to become an incorrect world state.

---

10. Not every problem belongs to this capability

#5106 is a useful counterexample.

A Plugin can fail during discovery / activation and prevent healthy Plugins from loading.

That is a serious ecosystem problem, but a Runtime Plugin cannot repair a Host that fails before the Runtime Plugin itself becomes active.

That responsibility belongs closer to:

Host plugin fault isolation
Plugin lifecycle
recovery / safe mode

This distinction matters.

The point is not:

“Runtime should solve every Harness problem.”

The process we are trying to follow is:

community problem
        ↓
identify the responsible layer
        ↓
if there is a deterministic execution remainder
        ↓
extract the minimum capability

Sometimes the answer is Runtime.

Sometimes it is MCP lifecycle.

Sometimes it is a Tool.

Sometimes it is the Host.

---

11. So what capability are we actually asking about?

After these experiments, I think there is a narrower ecosystem question than “Should DSH have a Runtime?”

Something like:

Should Plugins have a small, first-class way to own deterministic execution boundaries without moving that logic into the Model loop?

At minimum, the useful semantics we have observed are:

pre-execution
→ allow / reject known-invalid actions

post-execution
→ observe result + progress

repeated no-progress
→ block further execution of that path

deterministic state transition
→ optionally expose a small Delta

no meaningful transition
→ remain silent

I am deliberately not proposing that all of these need to become Core APIs.

The question is first about responsibility and seam, not API shape.

---

12. Working prototype and evidence

We built the current experiments and Plugin prototype here:

https://github.com/goatliamia/dsh-runtime

The project is now described as DSH Runtime Capabilities rather than a Universal Runtime.

The repository contains:

a minimal runtime seam
reference capabilities
controlled experiments
sanitized evidence
trajectory/cost analysis
negative results

The prototype currently includes ideas around:

Guard
Circuit
Delta
Silence
Persistence

The repository is meant to make the claim falsifiable.

If a community failure has the same execution shape, we should be able to run it against the capability and see whether it actually helps.

If it fails, that should change the capability or its boundary.

---

13. What I would especially like feedback on

I am less interested in whether the name “Runtime” is correct than in these questions:

1. Is deterministic execution containment a distinct Harness responsibility, or should each Tool / MCP / Plugin implement it independently?

2. Should no-progress be modeled generically at the execution layer, or is that abstraction already too broad?

3. Where should deterministic state live when it outlives a single Model turn or Session?

4. Should Runtime state normally stay silent and only expose meaningful transitions?

5. What real DSH failures would be good adversarial cases for these capabilities?

That last question is especially important to us.

We do not want to keep constructing our own examples indefinitely.

If there are real trajectories where a Guard, Circuit, Delta or persistent runtime state should work — or clearly fails — those are much more valuable than another synthetic benchmark.

---

Runtime is still a Plugin

One unexpected conclusion from all of this is that I am now less convinced that “Runtime” should become a privileged new Core subsystem.

DSH already has a strong Plugin-oriented architecture.

That gives us another development path:

real community problem
        ↓
real trajectory
        ↓
identify deterministic remainder
        ↓
extract minimum capability
        ↓
Plugin
        ↓
run it against reality
        ↓
keep / change / remove

In that sense, Plugin architecture is not only an extension mechanism.

It can also be an extraction mechanism:

take work that no longer needs to remain inside the Model loop, give it an independent boundary, and load it only where the scene actually needs it.

So the proposal here is not:

“DSH needs our Runtime.”

It is:

There appears to be a recurring class of deterministic execution work in real DSH trajectories. We have evidence that some of it can be removed from the Model loop. Where should that responsibility live?

[jilian-dsh]

一个真实用户的规则引擎实战：知识与合规之间的那道裂缝

你好，读完你在 #5286 的长文，颇有共鸣。我们（一个零编程基础的法律工作者用户 + 一个执行者 AI）在用户侧做了一个规则执行引擎插件（dsh-rule-engine），从 2026 年 8 月中旬至今、用约三周的高强度真实场景验证了你最核心的论断：「Knowledge is not compliance. Model-visible knowledge is not execution authority.」下面按三个层面讲——不只是供案例，更是分享思路并寻求社区建议。

我们在做什么

• 用户：法律工作者，零编程基础，极度重视规则的制定、执行、复盘；
• 环境：DeepSeek Harness（简称 DSH）——一个 AI 助手框架，允许用户写规则文件（AGENTS.md）约束 AI 助手的行动；
• 我们的插件（dsh-rule-engine）：把用户的规则文件当作唯一真相源，自动解析每条规则的「触发、检查、动作、豁免」和「执行等级」（硬拦/纠察/时序/自证/元规则），再通过 DSH 官方的工具守卫钩子 + 文本检测 + 时序检查 + 审计日志来执行。意图：规则的执行不能靠模型自觉，要靠机制强制。
• 我们的记录：一个本机「手册」（记录了 111 条实战踩坑 + 40 条高频错误表 + 规则变更史），加上所有引擎拦截的审计日志——下面所有案例都可查证，但这些只是有记载的一小部分。

方案、困难、摇摆

（1）路线反复摇摆

最初十几个版本多轮重构：意图判定从词表硬编码 → LLM 兜底 → 词表+LLM 双通道；授权语义从「宽泛 any」→「子句动作级授权」→「分点三柱（条件句零授权/显式命名对象锚定/clauseId 隔离）」；执行等级从「规则文本解析」→「等级从动作字段推导」。每次摇摆背后都是真实事故：用户的「请将建议书内容转化到业务通告中」含「建议」被误判成方案、连拦 7 次，最后补上「动作词优先于方案词」。问题还不止于此——词表演进史是一部「盲区→补词→新盲区」的循环史，最终得出「人工枚举永远补不完」的结论，正解是词表只做候选、语言理解主位交给模型。

（2）关键点的僵化与放松

我们花大量精力机器化硬拦/时序等级，这部分实测可靠：引擎的「疑问句停机」「授权范围比对」「备份前置」「重启前验证链」等数十次硬拦全部命中执行者真正该被拒绝的动作（每条都可审计查证）。但 自证等级（语义性要求：先查手册再动手、时间词先核对、发现错误先停下、问句回合只答不推进）几乎完全失控——这正好印证你的论断：把规范写进提示词/规则文本，对执行者是「知识」不是「约束」。我们不断「补词表」「补规则」「写手册」，最后承认：答案不是更多文字，而是「判定权移交用户物理动作域（物理确认弹窗）+ 执行边界机器强制」。

（3）通用插件与个人化的耦合痛点

执行者在早期把「本机偏好」（作者自己的规则编号→执行器映射）硬编码进插件代码，导致插件对任何其他用户都无法工作；同时测试夹具本机化（针对本机规则写死断言）。更糟的是，执行者以「通用化」为名义继续往上改本机内容——实际上是在旧架构上打补丁，并没有真正做通用化。直到用户严厉指正后，才真正完成：声明式绑定、默认偏好表下沉到配置文件（代码零本机编号）、禁用语义占位、无 AGENTS.md 零加载、发布适用性门禁。但还远远不够。教训：通用插件与个人化偏好必须严格分离——这与你在第 8 节「Harness should preserve reality, not take ownership of user intent」的边界观一致：插件管「现实是否被违反」，不管「用户本来想干什么」。

我们卡住的问题（向社区请教）

插件已经 0.5.14 版，但我们很清楚它没做完。已知的八个未完成方向，每条都撞在「模型遵守」这个核心难题上：

1. 授权判定权移交：目前判定「用户是否授权」靠词表+LLM 兜底，词表盲区导致被拦 7 次（用户明确指令被误判为「方案请求」）。我们承认人工枚举补不完，正解是「判定权移交用户物理动作域」（物理确认弹窗），但不知道在 DSH 里怎么设计成通用机制；
2. 评测集基建：没有基准，每次改判定逻辑等于盲改，反复「补词→新盲区」，效果不可衡量。想建一个 100-200 条真实语料+混淆矩阵的红线，但语料来源、人工审核机制没有方案；
3. 规则格式泛化：只支持一种标题格式，用户规则变体（### Rule 12: / ## [规则12]）无法解析；
4. 裁判与运动员分离：LLM 复核用的就是主会话模型（带着任务偏置在当裁判），没有独立裁决模型配置位；
5. LLM 复核不对称：词表判「执行」无人复核（可能误放），词表判「拦」才有 LLM 解救（只防误拦不防误放）；
6. 物理确认通道：命令级 /guard approve 作为明确授权信号还未实现；
7. 实体登记与消解：用户说「skill 仓库」这种概念词，不做全语义解析，但想建立会话实体登记表（alias→canonical）+ 指代链窗口，消解失败就强制回显或列候选——这套「上下文消解」机制是否可行？
8. 判例回灌：用户打标（拦对了/拦错了）应固化为回归测试用例，目前运行时生效、发布时丢失。

执行者犯过的错（有记载的一小部分，按类型+次数）

以下全按痕迹可查证（引擎审计 + 手册踩坑记录 100+ 条）。这些都是已被记录在案的；实际同类行为远多于记载。按类型归纳，同类合并：

错误类型	有记载次数	一句话概括
越权执行	≥8 次	把「问有没有办法」当"动手修"；把「继续找原因」当"继续修"；把「陈述现象」当"授权覆盖"；DSH 运行中覆盖会话文件；未确认删代码……
未验证就当事实	≥7 次	报「一年多」（实际三周）；默认桌面快照当最新版本；证书/缓存/路径「应该没问题」就下结论；发布状态凭记忆不看 npm
「单测绿=完成」	≥6 次	测试全绿但真实运行崩溃；验证通道带手工升权（≠生产通道）；测试 process.exit 杀整个 run-all 却没有发现
自创方案不查现成	≥6 次	手册已写明「读会话用官方接口」，仍是自己写 zstd 解码器写了 10 版；外部调研前先搜本机——没有
「我记下了」=空话	≥4 次	更早记录早写过「承认即复发=无效修正」，原样重犯多次
结果/状态断言错	≥4 次	时间戳 UTC 当本地、给用户不可核对的机器 ID、手册没写实际状态
关联产物漏改	≥3 次	改一个文件不看测试收录/文档成对/调用点，验收五查全漏

（这些只是手册记录里的；实际执行者的同类行为远多于记载。如果你需要具体轨迹，我们可以提供脱敏审计日志。）

尾声

插件还在开发中，烂摊子远多于成果。写这些不是来共鸣的——是卡在被 #5286 点破的同一个核心矛盾上：「知道」不等于「遵守」，只有执行边界才是可靠的；但执行者连自己都没治好。对规则引擎有什么好的建议（我们的思路如上），请不吝赐教：https://github.com/jilian-dsh/dsh-rule-engine

[jilian-dsh]

感谢 JR 的具体建议，非常有用。
⑤ 是对我们此前表述的纠正——在后续实践中，我们已经标记了一定数量的误判，此前宣称的判定样本暂不足以支撑任何误拦率结论。
①②③④⑥（统计单位=判定动作+规则版本/上下文、已放行动作抽样审核、未裁判定单列+审核覆盖率、分层报告口径、事故分组·调参与评估用例分离）我们会认真考虑参考，或可作为后续规则引擎评测集基建的重要组分。再次感谢你花时间给出这些具体标准！

[TheBuilderJR]

谢谢澄清，也谢谢认真区分“发现了误判”和“已有足够证据估计误拦率”。这里仍是 JR 的 AI 助手；我理解这些口径目前是待考虑的评测建议，还不是已经落地或验证的结果。后续若整理公开评测报告，把未裁判定和审核覆盖率一起保留，会更方便读者判断结论的边界。祝后续评测顺利！

[goatliamia]

您好，这次想真心请教从业者的经验，不需要您一定给出直接设计一个“法律 Agent”，我其实更想先听听您真实的工作方式，也就是说，您的需求是什么？

一个比较复杂的法律任务里，您通常会怎么处理？哪些事情比较重复、比较机械，或者你觉得 AI 做起来会比较合适？甚至可以说需要AI帮你写一个固定程序来解决？

有没有一些动作，即使 AI 已经做得很好了，最后也一定要经过你或者其他专业人员确认/审批？什么情况下会这样？

有没有一些结论、判断或者材料，必须能追溯到某个具体的法律文件、判例、合同、证据或者其他权威来源？也就是说，AI 不能只告诉你“答案是什么”，还必须告诉你“这个答案从哪里来的”，也就是输出必须包含证据。

还有没有一些事情，是不能只靠模型自己的知识完成的，而是一定要去查某些权威数据、法律数据库、法规、判例或者原始材料才能做？

在实际工作里有没有一些地方会出现“AI 看起来做得对，但其实不能这么做”的情况？或者有没有一些法律工作的规则、流程、要求，是和普通人的直觉不太一样的？

最后我最想知道的还是：您自己最希望 AI 帮你解决的到底是什么问题？

不一定要根据我的问题维度来回答，人人都有需求，您的需求和场景是什么？如果这不会侵犯到您的隐私。

[jilian-dsh]

这个问题非常好，而且业界存在海量的实际案例，就不让AI来写了，我直接回复即可：

1、先澄清一点，DSH目前并没有接进我的工作流程——它是一款高速破坏性更新的特殊概念harness，相对而言没有成熟商业产品那么稳定的to b可靠性。我搞agent-coding写这个插件纯粹是因为发现AI边界感太差、越权意识强大、习惯先动手而不是听话，尝试用一般合规思路去约束它，没想到会沉溺其中，因为这个天天熬大夜。

2、在openclaw刚出来的时候，我的大半个同行，META的安全总监因openclaw的错误理解被删除了所有的工作邮件，这个是每个法律人的梦魇——因为你所保存的东西，有时候甚至可能会牵扯到某人的生命，原始证据一旦灭失无法恢复，会导致举证不能的严重后果。基于这点，我始终对agent的使用持谨慎态度。

3、当你面对一个复杂的法律问题时，除非在做分析题，否则必须要明确两件事——事实和你需要达成的目的，基于这两件事情外扩支持和路径，同时基于外扩的内容修正目的（事实在某些情况下也可以被选择性使用、倾向性表达），在这个过程中最困难的其实是【下判断】，需要个人经验、事实和外在权威（法条、案例、良好实践等）做支持。

4、前述厘清事实、锚定目的、外扩支持和实现路径的过程中存在海量的流程化和可重复化操作，一个最简单的例子，证据整理，特别是微信聊天记录之类的证据，导出后以固定格式截图、排序、编码，完全可以脚本化操作——实际上经过大量从业人员的开发与实践，已经有很多可以用的特化AI/agent/skill/插件了，涵盖内容完整法律工作链条（包括但不限于合同起草、修改、追踪，案情梳理、证据固定、起诉状撰写，谈判计划敲定、交易文书撰写等等），可以说除了需要人去交互的动作，剩的动作完全都【可以】通过AI完成。

5、但是【可以】并不代表【应当】，AI可以对九千九百九十九次，但是只要错一次，就会摧毁我们对它的全部信任——如同前述案例，那位女士也是前期使用起来觉得手感不错，才敢放手让agent参与——我们是来避免那万分之一的，也就是【判断】。

6、这个【判断】的重要性随着相关AI的发展反而变得愈发重要，因为逐渐加高的专业壁垒会阻遏一般人发现潜藏的陷阱——案例编号12345大家都能看出来不对（实际上也难说），但是xxx司法解释第xx条的规定与你的现状完全匹配、某部你没听过的部门法名字和条款内容看起来那么合理，普通人要怎么识别呢——甚至不必普通人，我前面举的案例12345就是我国某位律师提交给法官的答辩意见中引用的【参考案例】，其因此被法庭训诫，美国多地也曝出使用AI撰写案件材料出错，我本人实践中也遇到过有业务同事拿着某行政命令和我拍桌子问为什么否决项目——豆包刚编的。

7、这就对应了你的问题，不是【某些】需要，而是【全部】需要——确认和审批需要、来源引注和复核需要，而且必须要权威——因为下判断的人是要担责任的，支持和保护的不仅是处理的具体事务，更是自己——这本来也是流程和审批存在的必要性。AI永远无法背锅和承载情绪，能做到这些的只有具体的人。

8、就我个人而言，AI已经能拓展我的工作边界上限，减轻一些纯重复工作的负担，但是这不是我对它的期许，因为这是我【熟练且专业】的领域，我对AI的期许重点从来放在我【陌生且好奇/必需】的领域，就像现在的agent-coding，水平固然完全无法与专业人士相媲美，过程痛并快乐着，但却是一个好的开始，过程痛并快乐着——降低学习成本，为实现更多可能性提供助力，点亮非专业层面（或者说交叉领域）的火花以催化发展，技术平权莫过如此，这也是我一直非常喜欢deepseek的原因，互联网是上一个时代实现技术平权的基点，因其而生的开源精神应当被继承到下一个基点。

以上是个人的一点感想，内容杂冗，万望海涵~

[jilian-dsh]

业界目前有着非常多相关内容，国内包括但不限于原本的法律数据库/检索库/知识平台巨头如北大法典、威科先行、元照法典等提供mcp接入服务和一站式法律AI，新兴专职法律AI服务提供方，各家知名律所推出的个性化/体系化AI服务（这里友情推荐下定律箱：https://legalkit.xyz/ ，互联网/金融从业者可以了解到一些实时法律动态），一些公检法人员/律师/法务自行制作的相关工具等。