为什么 agent 守门人比 agent 框架更先成熟:Conduct 给出的工程判断 2026 年 8 月 28 日,HN 上线了一个 Show HN 项目 Conduct——作者 sudhendra1 自述动机是"被一次又一次因为 agent 把 Slack token 泄给 Claude 而被叫醒"。他给出的解法不是又一个 agent 框架,而是一个 OpenAI-compatible pr
为什么 agent 守门人比 agent 框架更先成熟:Conduct 给出的工程判断
2026 年 8 月 28 日,HN 上线了一个 Show HN 项目 Conduct——作者 sudhendra1 自述动机是"被一次又一次因为 agent 把 Slack token 泄给 Claude 而被叫醒"。他给出的解法不是又一个 agent 框架,而是一个 OpenAI-compatible proxy 加上 MCP tool hooks,在 LLM 和 MCP 调用真正打到 provider 之前,集中阻断"凭据泄漏、prompt injection、超出策略的工具调用"。每一次决策都被 hash chain 记录,可以事后证明 agent 实际做了什么事。这个项目的工程位置非常微妙——它和 Claude for Commerce、OneCLI、Graft 同期出现,但瞄准的不是"agent 怎么把事做对",而是"agent 在做错之前被拦下来"。这件事揭示了一个被低估的事实:在企业 agent 落地这件事上,守门人(Guardrails)的成熟速度可能比 agent 框架本身更快。
把 Conduct 放在 2026 下半年的整体版图里看,会发现它解决的是 Claude for Commerce 没有解决、OneCLI 没有解决、Graft 和 ripwire 也没有解决的最后一公里——LLM 与 MCP 调用的"前置政策拦截"。Claude for Commerce 在 prompt 和 tool contract 层做围栏,但它是"agent 框架内置的安全";OneCLI 做的是 sandbox + 凭据注入网关,但它假设 agent 是 well-behaved 的;Conduct 直接坐在 LLM 调用链路上,作为一个 fail-closed 的政策引擎,任何不符合策略的请求在到达模型之前就被拒。这三件事解决的是不同层次的问题,合在一起构成企业级 agent 落地的完整防御链。
Conduct 是什么:一个"前置拦截"政策引擎
Conduct 不是一个 agent 框架,不是一个 agent harness,也不是一个 LLM 网关,它把自己定位为"control plane for AI agents"。整套架构由三层组成:Guard(政策引擎)、Router(LLM proxy)、Lens(查询界面)。三层共享同一套策略,意味着开发者在 Cursor 里写的请求、CI 里跑的 scheduled agent、平台上的 chat 会话,都会被同一份 policy 审查。
安装方式刻意做得极简:`pip install conduct-cli` + `conduct login` + `conduct sync`,三步搞定。一次安装同时让 Claude Code、Cursor、Copilot、Codex 在同一台机器上的所有 session 进入治理范围。任何被 block 的调用都会返回一个 `Receipt: https://conductai.ai/theguard/blocks/…` URL——点进去能看到具体被拦下的原因、关联的工具调用、能通过 Lens 跟进询问。这种"block + receipt + drilldown"三件套是 Conduct 区别于传统 runtime firewall 的核心:它不是只告诉你发生了什么,而是告诉你为什么、并且让你能立刻追溯到具体一条调用。
作者把它和已有的"runtime firewall"类工具(Straiker、Lakera)做了直接对比:Straiker 和 Lakera 是"事后观测"——agent 调用完之后告诉你它做了什么;Conduct 是"事前决策"——agent 调用之前就告诉你它能不能做。这个 timing 上的差异,在合规和事故复盘场景里有完全不同的价值。前者能写 incident report,后者能 prevent incident。
三层证据链:signed config + hash chain + fail-closed
Conduct 在 README 里反复强调的"能在审计室里立得住"的三个性质,是它作为企业级守门人的工程基线。
第一条:signed config。每一个 workspace 都会对自己激活的 policy set 做签名,Guard 在执行任何决策前先验证签名。任何被篡改的策略包会在决策之前就被拒绝——这意味着即使 attacker 拿到了 system 权限、修改了 policy 文件,也无法让 Guard 执行新策略,因为签名校验会失败。这条性质把"策略完整性"从可选项变成了硬约束。
第二条:SHA-256 hash-chained audit。每一次 Guard 决策都 append 到一条 SHA-256 链,锚定在 workspace genesis。任意一条记录被改,链条就会断;任意一段记录被删,链条也会断。审计人员只需要一行命令就能验证整条链是否完整,而不需要信任 Conduct 的服务端。这种"无需信任服务端就能验证"的设计,是企业合规场景下的硬需求。
第三条:policy-first,而不是 detection-first。规则在动作执行前就做出"block / warn / audit / inject"决策,带结构化理由;不是事后靠异常评分识别问题。前者意味着 agent 永远不能"先做了再被纠正",后者只能做到"事后追究"。在合规要求"双人复核"或"关键操作前确认"的场景里,policy-first 是唯一可行路径。
这三个性质合在一起,构成了 Conduct 和 Straiker/Lakera 在合规价值上的根本差异:后者是 observability 工具,Conduct 是 governance 工具。前者告诉你"发生了什么",后者决定"能发生什么"。对企业安全负责人而言,这两个角色都不可或缺,但 governance 显然优先级更高——因为只有 governance 能 prevent 数据丢失和凭据泄漏,observability 只能在事后告诉你"已经发生了"。
为什么 fail-closed 比 fail-open 更适合企业 agent
Conduct 明确把"fail-closed"作为默认行为:Guard 自己出错时(比如网络断开、策略文件损坏、签名校验失败),默认行为是"拒绝所有调用",而不是"放行所有调用"。这和传统 runtime firewall 的 fail-open 默认值正好相反。两种取舍的工程含义完全不同。
Fail-open 的逻辑是"可用性优先"——如果安全工具出错了,不应该把整个 agent 系统一起带挂,所以默认放行。问题是:对一个治理 LLM/MCP 调用的守门人来说,默认放行意味着"如果守门人挂了,agent 就回到了裸跑状态"。而 agent 裸跑可能导致的损失(数据丢失、凭据泄漏、生产事故)在大量场景里是远大于"agent 暂时不可用"的损失。所以 Conduct 的判断是:宁可短暂失去可用性,也不能冒治理真空的风险。
Fail-closed 的代价是工程上更难做。守门人必须自己保证高可用(否则一天到晚 fail-closed 谁都用不了)、必须提供清晰的错误反馈(否则 agent 和用户都搞不清发生了什么)、必须有 fallback 路径(否则关键任务会卡死)。Conduct 用三层 surface(Guard / Router / Lens)共享同一份策略的方式,部分解决了"治理真空"的问题——即使 Guard 自己挂了,Routing 仍然可以让请求被 fail-closed 处理,而不是 fail-open 裸跑。
对企业技术决策者,fail-closed 的取舍意味着:任何想做 agent 守门人的工程团队,都不应该假设"守门人永远在线"——必须为守门人挂掉的情况设计独立的降级策略,而不是简单回到"无守门人"的状态。这是 OneCLI、Claude for Commerce、Graft 都没有显式讨论、但实际生产里绕不开的一个细节。
从发现到治理:Discovery 模式的工程意义
Conduct 提供了一个 14 天只读的 Discovery 模式,在这段时间里它只记录所有 AI 动作、不主动拦截任何调用。14 天结束后,企业可以根据 Discovery 看到的数据,决定哪些动作应该被 promote 成 block 规则、哪些应该继续 audit、哪些可以完全放行。这种"先观察、后治理"的工程姿态,是企业级守门人区别于通用 LLM 网关的另一个关键特征。
通用 LLM 网关往往假设客户已经有明确的策略——你给我一份规则文件,我严格执行。但企业 agent 落地的现实是:大多数团队并不知道自己应该禁止什么。agent 在企业里到底会做什么、哪些是危险的、哪些是 OK 的、哪些需要在 review 后才能放行——这些信息只有在真实使用了一段时间之后才能浮现。Discovery 模式正好填补了这个 gap:它把"治理策略"从"开局就要写"变成了"用着再写"。
这个工作流也回应了一个常见的反对意见——"agent 治理会拖慢工程师"。如果 agent 一上来就被一堆 block 规则挡着,工程师会感到 friction、绕开守门人、甚至放弃使用。但如果先跑两周 Discovery、看清实际发生了什么,再根据真实数据 promote 关键规则,friction 会显著降低,守门人也更容易被接受为"基础设施"而不是"麻烦制造者"。
守门人赛道的边界:Conduct 不是万能的
把 Conduct 的能力和 Claude for Commerce、OneCLI、Graft、ripwire、Claude for Commerce 的能力放在一起,会发现它解决的是一个相对精确的子问题:LLM 和 MCP 调用的策略前置拦截。它不解决以下几件事:
agent 推理质量——这是 Claude for Commerce、Graft、ripwire 的领域,守门人不关心 agent 的 reasoning 是否合理,只关心 agent 调用模型/MCP 时是否违反了 policy。
agent 运行环境隔离——这是 OneCLI 的领域,守门人不关心 agent 跑在 sandbox 还是 bare metal,只关心每个 LLM/MCP 调用是否在策略允许范围内。
数据持久化与压缩——这是 ACM(Agentic Context Management)论文和 Context Compaction Theory 的领域,守门人不关心 agent 的 memory 是否最优,只关心每次调用的 input/output 是否触发了凭据泄漏或 prompt injection。
理解这些边界对工程团队很重要:Conduct 不是 agent 工程的"一站式解决方案",它是治理层一个特定子问题的解。把它的能力定位错,会导致团队以为"装了 Conduct 就万事大吉",结果仍然在其他子问题上踩坑。正确的姿态是把它当作企业级 agent 治理工具链里的一块,与 OneCLI(运行时隔离)、Claude for Commerce(场景围栏)、Graft/ripwire(上下文效率)组合使用。
从工具到协议:Guardrails 在企业 agent 落地里的真实位置
Conduct 上线的同时,HN 评论里还有两个相关项目:crates.io 上的 coding-tools("更轻量,聚焦 harness tool calls")和 LuD1161/agentjail("OPA-backed policies + os-native sandbox")。这三个项目加上 Straiker、Lakera 一起,正在形成一个相对清晰的市场分层:Conduct 做"前置治理"(policy-first),coding-tools 做"harness 内 hooks",agentjail 做"sandbox 内 OPA",Straiker/Lakera 做"事后观测"。
这种分层不是偶然——它意味着企业级 agent 守门人正在从单一产品形态,演化成一套协议化的分层架构。每一层解决不同子问题、用不同技术栈、对接不同合规要求。一家认真做企业 agent 落地的公司,最终会同时部署多层治理:policy layer(Conduct 之类)、sandbox layer(OneCLI / agentjail)、harness hooks(coding-tools / Claude for Commerce 围栏)、observability layer(Straiker / Lakera)。
对企业技术决策者,这意味着评估"agent 守门人"产品时,不能用"是否解决全部安全问题"作为判断标准——而是问"它解决的是哪一层的问题、和现有栈如何组合、需要多少工程投入才能上线"。Conduct 这种"前置 policy + fail-closed + signed config + hash chain"的组合,在四层架构里属于最稀缺的一类——市面上"事后观测"类产品已经很多,而"前置治理 + 可验证审计链"类产品才刚刚开始出现。把它作为企业 agent 治理栈的关键组件、围绕它设计 policy、把它和 sandbox / harness hooks 拼起来,可能是未来 12 个月企业 agent 落地最值得投入的一个方向。