Building Enterprise Agent Systems that People can Trust, Verify and Improve

构建企业级智能体系统：让人们能够信任、验证并持续改进

Agentic AI 智能体 AI

5 principles that determine whether an agent system succeeds in production, explained through one I built for a $100M+ company. Sheila Teo Aug 18, 2026 17 min read. 决定智能体系统能否在生产环境中成功的 5 个原则，通过我为一家价值超 1 亿美元的公司构建的系统进行解析。作者：Sheila Teo，2026 年 8 月 18 日，阅读时长 17 分钟。

I help enterprises build agent systems that automate their operational workflows. Across my work, I’ve found that teams often put most of their time and effort into engineering the agent harness, while giving far less attention to the product, workflow and human decisions that determine how it operates inside the business. 我致力于帮助企业构建自动化运营工作流的智能体系统。在我的工作中，我发现团队往往将大部分时间和精力投入到智能体框架的工程实现上，却很少关注那些决定系统如何在企业内部运作的产品设计、工作流逻辑以及人为决策。

When those decisions aren’t thought through carefully, I often see sophisticated agent systems get deployed yet change very little about how work actually gets done. I’ve distilled my experience into 5 principles for building agent systems that succeed inside a business, earn people’s trust and improve over time. 当这些决策没有经过深思熟虑时，我经常看到复杂的智能体系统虽然部署了，但对实际工作方式的改变微乎其微。我将自己的经验提炼为 5 个原则，旨在构建能够在企业内部取得成功、赢得人们信任并随时间推移不断改进的智能体系统。

This article explains each one through an agent system I built for a $100M+ managed IT provider, to address one of its most pressing problems at the time: client churn. 本文将通过我为一家价值超 1 亿美元的托管 IT 服务商构建的智能体系统，来逐一解释这些原则，该系统旨在解决当时公司最紧迫的问题之一：客户流失。

1. Tailor the product shape to the business workflow
2. Give each workflow step to the simplest mechanism that handles it well
3. Redesign the human’s job at the agent handoff
4. Design the agent handoff for human verification and feedback
5. Build a self-improvement loop from human feedback
6. 根据业务工作流定制产品形态
7. 将每个工作流步骤交给最能胜任的简单机制处理
8. 在智能体交接环节重新设计人类的工作职责
9. 为人类验证和反馈设计智能体交接流程
10. 基于人类反馈构建自我改进循环

The case study: Detecting churn risk hidden across service tickets

案例研究：检测隐藏在服务工单中的流失风险

The company runs IT operations for its clients and was facing unprecedented client churn at the time. One of the clearest warning signs is a service issue that keeps coming back for the same client. The problem is that this warning almost never arrives as a warning. Instead, it arrives as separate incidents spread over weeks or months. Each incident looks small and self-contained. 该公司为客户运营 IT 业务，当时正面临前所未有的客户流失。最明显的预警信号之一是同一客户反复出现相同的服务问题。问题在于，这种预警几乎从不会以“预警”的形式出现，而是表现为分散在数周或数月内的独立事件。每个事件看起来都很小且互不相关。

The commercial risk only becomes visible when someone notices that the same underlying problem keeps returning. Spotting that pattern meant relying on busy people to connect the dots. Support technicians saw individual service tickets raised by clients. Account managers reviewed client touch points and dashboards. For the risk to surface, someone had to remember the earlier incidents, judge whether they formed a pattern, gather the evidence and alert the person who owned the client relationship. 只有当有人注意到同一个潜在问题反复出现时，商业风险才会显现。发现这种模式意味着要依赖忙碌的工作人员去“串联”这些信息。支持技术人员只能看到客户提出的单个工单，客户经理则查看客户接触点和仪表板。为了让风险浮出水面，必须有人记住之前的事件，判断它们是否形成了某种模式，收集证据，并提醒负责该客户关系的人员。

Across many clients and a high volume of service tickets, connecting those dots by hand was prohibitively manual. The company couldn’t keep tabs on every client and every risk signal consistently at scale. 面对众多客户和海量的服务工单，手动串联这些信息的工作量大得惊人。公司无法在规模化的情况下持续跟踪每一位客户和每一个风险信号。

Tailor the product shape to the business workflow

根据业务工作流定制产品形态

The common instinct I see most teams follow is to put an agent system behind a chat interface. This company tried that route, too. The team first investigated churn through its enterprise data agent, a separate system I’d previously built for them so employees could ask questions about company data in natural language. 我看到大多数团队的惯性思维是将智能体系统放在聊天界面之后。这家公司也尝试过这种路径。团队最初通过其企业数据智能体来调查流失情况——这是我之前为他们构建的另一个系统，允许员工用自然语言询问公司数据。

But in my experience, a chat interface is often the wrong product shape for most enterprise workflows, for 2 reasons: 但在我的经验中，对于大多数企业工作流而言，聊天界面往往不是合适的产品形态，原因有二：

1. It waits for someone to think of the right question at the right moment. Business work usually starts because something happened, not because a person remembered to ask about it. In this case, early churn detection has to begin when new evidence arrives and keep running in the background.

2. 它需要等待某人在合适的时机想到正确的问题。业务工作通常是因为发生了某事而启动，而不是因为有人记得去询问。在这种情况下，早期流失检测必须在有新证据出现时就开始，并持续在后台运行。

3. It makes employee adoption a prerequisite for the business outcome. For adoption to just work, the agent system has to run without anyone needing to drive it. Ideally, it should also require minimal change to existing behaviour.

4. 它将员工的采纳作为业务成果的前提。为了让系统顺畅运行，智能体系统必须在无需任何人驱动的情况下自动运行。理想情况下，它还应尽可能减少对现有行为的改变。

The company’s churn risk workflow also depends on patterns that build up over time. To run efficiently, the system should retain what it has already learned about each client’s ticket history instead of rebuilding that history in response to every question. 该公司的流失风险工作流还依赖于随时间积累的模式。为了高效运行，系统应该保留其已了解的每个客户的工单历史，而不是在每次提问时都重新构建这些历史。

As such, I guided the team away from treating churn detection as another question-and-answer use case for its chat-based enterprise data agent. Instead, I built a separate, event-driven agent system. This choice shifts the system’s job from helping employees inspect churn risk to owning the detection work itself. The system watches for new evidence, carries each client’s ticket history forward and starts the right workflow without waiting for someone to prompt it. 因此，我引导团队放弃将流失检测视为聊天式企业数据智能体的又一个问答用例。相反，我构建了一个独立的、事件驱动的智能体系统。这一选择将系统的职责从“帮助员工检查流失风险”转变为“自主承担检测工作”。系统会监控新证据，延续每个客户的工单历史，并在无需人工提示的情况下启动相应的工作流。

Give each workflow step to the simplest mechanism that handles it well

将每个工作流步骤交给最能胜任的简单机制处理

The mistake I see teams make most often is handing an agent the entire workflow. For example, a value needs comparing, so the agent compares it. Or a result needs routing, so the agent routes it. Putting everything in one prompt can look simpler, but in production it folds exact rules, ambiguous investigation and commercial judgement into one opaque LLM run. 我看到团队最常犯的错误是将整个工作流交给智能体。例如，需要比较一个数值，就让智能体去比较；或者需要路由一个结果，就让智能体去路由。将所有内容塞进一个提示词（Prompt）看起来很简单，但在生产环境中，这会将精确的规则、模糊的调查和商业判断混杂在一次不透明的 LLM 运行中。

The strongest production systems I’ve seen and built don’t use the most sophisticated agent at every step. They give each step to the simplest mechanism that handles it well, so the complete workflow stays accurate, understandable and cheap to run at scale. 我所见过的和构建过的最强大的生产系统，并不会在每个步骤都使用最复杂的智能体。它们将每个步骤交给最能胜任的简单机制处理，从而确保整个工作流保持准确、可理解，且在大规模运行时成本低廉。

The real design work is deciding which steps belong to deterministic code or a specialized method, which need an agent and which have to stay with a person. The agent is one decision-maker inside the system and goes where judgement is needed, not everywhere by default. 真正的设计工作在于决定哪些步骤属于确定性代码或专门的方法，哪些需要智能体，哪些必须由人工完成。智能体只是系统内的一个决策者，它只在需要判断的地方发挥作用，而不是默认出现在所有地方。