构建 Agent_Sudo 让我学到的关于人工智能代理安全的知识（在我找到任何用户之前）

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

我发布了一个实实在在的产品。Agent_Sudo 是一个面向人工智能代理的本地权限网关：它位于代理的工具调用之前，根据策略以及请求的来源决定允许/拒绝/需要批准，并写入一个防篡改、基于哈希链的审计日志供你验证。使用 Python 编写，零运行时依赖，约 190 个测试用例全部通过，包含一个模型上下文协议服务器，提供用于 LangGraph 和 PydanticAI 的可运行示例，并已作为 v0.4.0 版本发布到 Python 包索引。

它很扎实。我为这项工程感到自豪。而迄今为止，我学到的最有用的东西几乎与代码无关。

我正处在弄清楚是否真的有人需要这个产品的过程中。以下是这一过程诚实地教给我的东西，尽管工作仍在进行中。

工程质量与市场需求是完全不同的变量

在几周的时间里，我通过工程师们衡量的标准来评估这个项目：测试全部通过、模块清晰、无依赖关系、抽象设计严谨。这些都是真实的，都令人满意，但它们都无法告诉你是否有一个人真正想要这个工具。

我发现自己用代码质量作为进度的替代指标。事实并非如此。一个构建精美但无人需要的产品，仍然是无人需要的产品。意识到这是两个独立的维度——即“它是否优秀”与“是否有人想要它”——是最具启发性的转变，而我显然在假设后者成立的同时，过度优化了前者。

我可能打造了一款维生素，却告诉自己它是止痛药

宣传听起来很紧迫：阻止提示注入，阻止数据泄露，审计一切。但退一步看。大多数开发人员已经从他们的工具中获得了权限提示，而只有当你确实将每个调用都通过网关路由时，网关才有用。对于独立开发者来说，这读起来像是针对你尚未遭受过的风险的一种“锦上添花”的功能。

存在一个更严肃的买家群体，即那些需要在多个代理之间实施真实授权策略和可验证审计轨迹的团队。这对他们来说是止痛药。但我尚未验证这一买家群体。因此，我现在带着一个诚实的开放性问题：我是在为人们感受到的痛点构建产品，还是为我自己觉得有趣的痛点构建产品？

我的演示证明了错误的事情（而且是我构建了它）

我制作了一个干净的 60 秒演示：一个代理读取被投毒的网页，试图泄露秘密，而网关阻止了它。看起来很棒。

然后我阅读了自己的代码。请求是手工编写的。“攻击”是硬编码的。执行是在空跑模式下运行的。它忠实地展示了决策逻辑，但却回避了真正困难的部分：拦截真实的代理并归因指令的实际来源（用户 vs. 模型 vs. 获取的内容）。这种归因是核心的技术主张，而演示只是断言了它，而非证明了它。

一个只叙述而不证明的演示，如果说有什么不同的话，比没有演示更糟糕——因为持怀疑态度的读者大约在一分钟内就能发现其中的差距，现在他们也不再信任其余部分了。构建一个真正能够拦截并归因的版本才是真正的工作，而这仍待我去完成。

分发结果比构建难得多

我曾假设构建是困难的部分。构建其实是简单的部分。

在尝试将其展示给人们的过程中，我有了一些具体的发现：

• 我发帖到了一个相关的子论坛。它被立即删除了，不是由版主删除的，而是被Reddit 的垃圾邮件过滤器删除的，因为我的账户只有1 点 karma（积分）。该账户已有五年历史；但这并不重要。没有声誉，就无法发帖。
• 我查看了官方协议社区的 Discord 服务器。其规则规定：禁止自我推广；拉拢行为属于可封禁的违规事项。这是一个贡献者/规范讨论空间，而不是展示产品的地方，这也合情合理。