背景
写过多 Agent 应用的都知道，模型只是冰山一角，水下那部分是 Harness——一堆管执行环境、工具调用、权限控制、日志审计的胶水代码。不难写，但脏：沙箱逃逸要防，敏感数据要拦，长程任务的状态要管，出了事还得有审计可查。Kimi 这次发布 Hosted Agents，思路就是把这一整层做成云服务。读完发布信息后觉得值得拆一拆，它的三层防线设计比较有代表性。
技术要点
第一层是执行沙箱。每个会话跑在独立沙箱里，互不串味，随时可中止。企业场景这是刚需总不能让一个 Agent 的失控循环把宿主机资源吃光。
第二层是网络权限控制。Agent 能访问哪些域名、哪些内网地址，白名单说了算。很多数据泄露事故的根源，是 Agent 被提示词注入后「顺手」把数据发到外部地址。网络层收口，比在提示词里求模型不要乱发可靠得多。
第三层最有意思：Inference Hook。它在每次推理调用之前生效，按企业规则扫描输入，命中敏感数据直接拦截。注意时机——是推理前，不是输出后。数据根本没进模型，泄露链条在源头就断了，这比事后审计的补救成本低一个数量级。
再把账算一下。自建的隐性成本：沙箱运维、权限系统、审计存储、Hook 规则维护，至少一到两名专职工程师。托管后这些换成订阅费，代价是环境锁定、定制自由度下降。我的建议是原型期用托管快速验证，合规要求特殊（比如数据必须境内处理）再考虑自建。另外 Agent 任务的 token 消耗远比聊天凶，多模型比价这个活我现在交给聚合平台来做做，跑批前先看一眼单价，一个月下来能省不少。
可运行示例
用零依赖标准库模拟一个最小 Harness 的权限检查与审计日志，演示「层级不匹配拒绝 + 高风险意图拦截」两个核心逻辑：
TASKS = [
("summarize_report", ["read_file"], "chat"),
("export_finance_csv", ["read_file", "run_sql", "write_file"], "enterprise"),
("wipe_database", ["read_file", "run_sql"], "enterprise"),
]
POLICY = {
"read_file": {"tier": "chat", "risk": "low"},
"write_file": {"tier": "enterprise", "risk": "medium"},
"run_sql": {"tier": "enterprise", "risk": "high"},
}
HIGH_RISK_WORDS = ("drop", "delete", "truncate", "wipe")
audit = []
for name, tools, tier in TASKS:
for tool in tools:
rule = POLICY[tool]
if rule["risk"] == "high" and any(w in name for w in HIGH_RISK_WORDS):
verdict = "deny(high-risk-intent)"
elif tier != rule["tier"] and rule["risk"] != "low":
verdict = "deny(tier-mismatch)"
else:
verdict = "allow"
audit.append((name, tool, verdict))
width = max(len(a[0]) for a in audit) + 2
for name, tool, verdict in audit:
print(f"{name:<{width}} {tool:<11} -> {verdict}")
denied = [a for a in audit if a[2].startswith("deny")]
print("total calls:", len(audit), "| denied:", len(denied)) print("open('audit.log','w').write(...):", len(audit), "entries exported")
summarize_report read_file -> allow
export_finance_csv read_file -> allow
export_finance_csv run_sql -> allow
export_finance_csv write_file -> allow
wipe_database read_file -> allow
wipe_database run_sql -> deny(high-risk-intent)
total calls: 6 | denied: 1
open('audit.log','w').write(...): 6 entries exported
wipe_database 的 run_sql 调用被高风险意图规则拦下——任务名里带 wipe，命中了 HIGH_RISK_WORDS。真实场景里这个匹配要精细得多，但「先查风险意图、再查层级匹配、最后放行低风险」的判断顺序是通用的。
踩坑提示
其一，审计日志别只记被拒绝的调用，放行的同样要记。事后溯源时「当时为什么放行」往往比「拦了什么」更关键。其二，关键词拦截有误杀和漏杀两面：任务名改叫 delay_old_records 就不会命中 delete，改名绕过太容易，关键词只能当第一道粗筛，认真的拦截得靠语义分类器。其三，Inference Hook 在流式输出场景下要确认拦截发生在首 token 之前，不然拦了个寂寞。
总结
Hosted Agents 的价值不在「又一个 Agent 平台」，而在把沙箱、网络权限、推理前拦截这三层防线做成了默认配置。对没有安全团队的公司来说，这比自己攒一套靠谱得多。下一步值得观察的是 Skills 生态的开放程度——140+ 只是起步，生态质量决定它能不能留住企业客户。
