案例研究：在部署给房地产经纪人之前，先内部测试Facebook代理

一家房地产公司找到我们，想要一个能运行他们Facebook页面的AI代理。不是调度器，而是一个真正的代理：* 摄取房源详情，* 生成房源帖子，* 安排并发布它们，* 并通过Telegram发送更新。在部署给他们之前，我们先在自己身上运行了这个系统。在过去的10天里，我们使用自己的运行时栈，针对我们自己的Facebook页面运行了一个相邻版本： * 本地模型（`qwen3-coder-next`） * 本地RTX 5090 * Telegram作为操作界面 * Facebook Graph API技能 * 哈希链审计日志 * 策略门控工具执行 * 出站发布前的人工审批 部署循环很简单：每天08:00、10:00和14:00，代理唤醒，拉取下一个排队的营销简报，以我们页面的语气草拟帖子，发送到Telegram等待审批，审批通过后通过Facebook发布。每个动作都会留下审计条目： * cron触发 * LLM生成 * 工具执行 * 审批事件 * 出站发布 每个条目都相互链接，因此运行时可以事后证明序列的完整性。 我们立即学到了一些东西： # 1. 漂移检测比发布内容更难 两个会话被标记为`accomplished=false`，尽管： * Facebook帖子已经发布， * 并且Telegram确认已经到达。 工作成功了，但会话记账没有成功。我们的漂移启发式在成功执行后触发，并错误地将该运行归类为未完成。这正是那种在演示中永远不会出现，但在生产循环中迅速暴露的问题。 # 2. 策略门控运行时比提示词更重要 在10天的运行中，模型尝试了六次shell访问。全部六次都在运行时层被自动拒绝。无需提示工程，无需“请别那样做”。运行时根本不暴露该能力。这强化了我们反复看到的一点：代理的可靠性更多地取决于运行时约束，而不是模型智能。 # 3. Facebook API的动态变化是实实在在的部署成本 在部署早期，我们在处理Meta权限和页面状态变化时反复遇到`graph_error`重试。到运行结束时，管道稳定了下来，但这强化了为什么大多数“代理演示”在操作部署之前就停止了。让模型生成文本很容易，但长期保持集成稳定性才是真正的工作。 # 运行时统计（10天） * 已发布帖子：15 * LLM调用：121 * 处理的令牌：879,875 * 被策略引擎阻止的工具调用：6 * 审批请求：7 * 审计事件：121个哈希链条目 * 首次通过成功的会话：33 / 42 我们这边的推理成本几乎为零，因为工作负载保持在本地硬件上。房地产经纪人的部署在结构上是相同的：Telegram输入，Facebook输出，中间有审批门。唯一的区别是内容队列。 我们先自己运行它的主要收获是：生产行为才是真正工程开始的起点。大多数代理失败不是生成失败，而是编排失败、状态失败、策略失败、重试失败或集成漂移。只有通过持续在真实表面上运行系统，才能发现这些问题。