Stop Letting Agents Run the Workflow别再让智能体掌控工作流了

A user submits a ticket: "Please grant temporary admin access to the finance reporting database for month-end close."用户提交了一个工单：“请授予我财务报表数据库的临时管理员权限，以便进行月末结账。”

A five-agent system handles it beautifully. A triage agent classifies the request. A policy agent checks entitlements. An approval agent decides a manager needs to sign off. An execution agent calls the identity API. A communication agent updates the ticket. The demo gets applause.一个由五个智能体组成的系统出色地处理了这一请求。分流智能体对请求进行分类；策略智能体检查授权；审批智能体判定需要经理签字；执行智能体调用身份 API；通信智能体更新工单。演示获得了阵阵掌声。

Three weeks into production, the same system grants a contractor standing admin access to a production finance database for 30 days instead of 8 hours because the classifier read "month-end close" as a recurring need, the approval agent inferred consent from an earlier message that said "manager aware," and the execution agent filled in a duration parameter the payload never specified.上线三周后，同一个系统却将生产环境财务数据库的长期管理员权限授予了一名承包商，期限为 30 天而非 8 小时。原因在于：分类器将“月末结账”误读为周期性需求，审批智能体从一条写着“经理已知晓”的旧消息中推断出同意，而执行智能体则擅自填补了一个载荷中并未指定的持续时间参数。

Nothing hallucinated. Every agent did roughly what it was asked. The system still failed, because no single component owned the process.并没有产生幻觉。每个智能体都基本完成了被要求的工作。但系统依然失败了，因为没有单一组件能够掌控整个流程。

This is the most common way enterprise multi-agent systems fail, and it is not a model problem. It is an architecture problem. This article describes the pattern I use to prevent it:这是企业级多智能体系统最常见的失败方式，且这并非模型问题，而是架构问题。本文将介绍我用来防止此类问题的模式：

Deterministic Spine, Agentic Leaves - Use deterministic workflow control for the business process. Use agents only as bounded workers inside controlled steps.
确定性骨干，智能体叶片 —— 针对业务流程使用确定性的工作流控制，仅在受控步骤内将智能体作为有边界的执行者。

This is not an observability pattern that helps you find the failure afterwards. It is a design-time pattern that makes the failure unrepresentable.这不是一种事后帮助你排查故障的可观测性模式，而是一种在设计阶段就让故障“无法发生”的模式。

What you'll get from this article: a diagnostic for whether your system has this problem, the four-layer pattern, a reference architecture on Microsoft Foundry, the schema contracts that make it enforceable, and a six-step implementation checklist.本文将为你提供：一套用于诊断系统是否存在此类问题的方案、四层架构模式、Microsoft Foundry 上的参考架构、使其可强制执行的模式契约，以及一份六步实施清单。

1. The failure mode: the agent quietly becomes the process owner1. 故障模式：智能体悄然成为流程所有者

Dangerous multi-agent systems rarely fail loudly. They usually look like they are working.危险的多智能体系统很少会大张旗鼓地失败。它们看起来通常都在正常工作。

A ticket gets created. A handoff happens. A subagent responds. A tool is called. The workflow advances. But the path is not guaranteed. The next step depends on what the model decided in that moment, based on prompt wording, context window contents, prior messages, tool descriptions, and sometimes stale state.工单创建，任务移交，子智能体响应，工具被调用，工作流推进。但路径并非得到保证。下一步取决于模型在当时所做的决定，而这又基于提示词的措辞、上下文窗口内容、先前的消息、工具描述，有时甚至基于过时的状态。

Run the same request twice and you can get two different process paths. In a brainstorming assistant, that is a feature. In an approval workflow, it is an unlogged control failure.运行同一个请求两次，你可能会得到两条完全不同的处理路径。在头脑风暴助手里，这是一种特性；但在审批工作流中，这就是一次未被记录的控制失效。

The specific failure modes are operational, not semantic:具体的故障模式是操作层面的，而非语义层面的：

None of these are hallucinations. All of them are workflow-control problems. They happen because the system has no single deterministic owner of state, transitions, permissions, and irreversible actions.这些都不是幻觉，全部属于工作流控制问题。它们之所以发生，是因为系统在状态、转换、权限和不可逆操作方面没有单一的确定性所有者。

A quick diagnostic快速诊断

Ask these four questions about any agentic system you are about to ship:在你准备发布任何智能体系统前，请问自己这四个问题：

1. If I run the same request 100 times, is the sequence of business states identical every time?如果我运行 100 次同样的请求，业务状态的序列每次都完全一致吗？
2. Can I name the one component that decides whether a transition is allowed?我能否指出那个决定转换是否被允许的单一组件？
3. Is approval a blocking gate in code, or an instruction in a prompt?审批是一个代码中的阻塞门，还是提示词中的一条指令？
4. If a tool call is replayed, does the business system change twice?如果重放一次工具调用，业务系统会发生两次变更吗？

If any answer makes you uncomfortable, the model is not your risk. Your control plane is.如果任何一个答案让你感到不安，那么风险不在于模型，而在于你的控制平面。

2. Microsoft's guidance already draws this line2. Microsoft 的指南早已划定了这条界线

This is not a contrarian take. It is the documented design distinction in Microsoft Agent Framework.这并非标新立异，而是 Microsoft Agent Framework 中明确的设计区分。

The framework separates two things deliberately. Agents are for open-ended work: the task is conversational, you need autonomous tool use and planning, and a single model call with tools is sufficient. Workflows are for defined processes: the steps are well-defined, you need explicit control over execution order, and multiple agents or functions must coordinate. As the documentation puts it, Agent Framework workflows "define explicit, inspectable execution paths for coordinating code, agents, state, events, and human input."该框架刻意将两者分开。智能体适用于开放式工作：任务是对话式的，需要自主的工具使用和规划，且单次模型调用配合工具即可完成。工作流适用于定义明确的流程：步骤界定清晰，需要对执行顺序进行显式控制，且必须协调多个智能体或函数。正如文档所述，Agent Framework 工作流“为协调代码、智能体、状态、事件和人工输入定义了显式且可检查的执行路径”。

Explicit and inspectable are the two words that matter for regulated enterprise processes.对于受监管的企业流程而言，“显式”和“可检查”是两个至关重要的词。

The wider industry has converged on the same boundary, which is a useful signal that this is architectural rather than vendor-specific. Anthropic distinguishes workflows, "where LLMs and tools are orchestrated through predefined code paths," from agents, "where LLMs dynamically direct their own processes and tool usage." LangGraph's documentation states that "workflows have predetermined code paths and are designed to operate in a certain order" while "agents are dynamic and define their own processes and tool usage." OpenAI's orchestration guidance separates handoffs, where control moves to a specialist, from agents as tools, where a manager retains ownership and calls specialists as bounded capabilities.整个行业已经就这一界线达成了共识，这有力地证明了这是一个架构问题而非特定厂商的问题。Anthropic 将工作流（“通过预定义代码路径编排 LLM 和工具”）与智能体（“LLM 动态指导其自身流程和工具使用”）区分开来。LangGraph 的文档指出，“工作流具有预定的代码路径，旨在按特定顺序运行”，而“智能体是动态的，定义自己的流程和工具使用”。OpenAI 的编排指南将移交（控制权转移给专家）与作为工具的智能体（经理保留所有权并调用专家作为有边界的能力）分离开来。

Four independent teams, one conclusion: when the process must be trusted, the process must be predetermined.四个独立的团队，得出了同一个结论：当流程必须被信任时，流程就必须是预先确定的。

The design decision follows directly:设计决策随之产生：

Use agents for intelligence. Use workflows for control. Use policy for authority. Use tools for execution.使用智能体实现智能化。使用工作流实现控制。使用策略实现权限。使用工具实现执行。

3. The pattern3. 这种模式

The core idea fits in one sentence:核心理念一句话即可概括：

The business process is a state machine. Agents are workers inside the states.业务流程是状态机。智能体是状态内的执行者。

The deterministic spine owns workflow state, allowed transitions, approval boundaries, retry behaviour, idempotency, timeouts, tool execution, audit events, and final action authority.确定性骨干负责工作流状态、允许的转换、审批边界、重试行为、幂等性、超时、工具执行、审计事件以及最终的操作权限。

The agentic leaves do bounded reasoning work: classify, extract, summarise, recommend, draft, compare, validate, explain, enrich.智能体叶片负责有边界的推理工作：分类、提取、总结、推荐、起草、比较、验证、解释、丰富。

The boundary is absolute:边界是绝对的：

• An agent can recommend the next step. It cannot move the workflow.智能体可以推荐下一步，但不能推动工作流。
• An agent can draft an approval summary. It cannot approve.智能体可以起草审批摘要，但不能进行审批。
• An agent can prepare an API payload. It cannot execute it.智能体可以准备 API 载荷，但不能执行它。
• An agent can identify a missing control. It cannot invent one.Figure 1. Deterministic Spine, Agentic Leaves. Agent leaves return structured contracts into states; they never advance the state themselves. Policy and approval gates sit before every irreversible action.智能体可以识别缺失的控制点，但不能凭空创造一个。图 1：确定性骨干，智能体叶片。智能体叶片将结构化的契约返回给状态；它们自身绝不推进状态。策略和审批门禁位于每次不可逆操作之前。

This is the difference between AI automation and agentic business process engineering.这就是 AI 自动化与智能体业务流程工程之间的区别。

4. Implementing it on Microsoft Foundry4. 在 Microsoft Foundry 上实施

Microsoft Foundry gives you the building blocks. The architecture decision is how you assemble them. Resist the instinct to build one "super agent" that owns everything, and implement four layers instead.Microsoft Foundry 提供了构建块。架构决策在于你如何组装它们。抵制构建一个掌控一切的“超级智能体”的本能，转而实施四层架构。

Figure 2.图 2。 Reference architecture on Microsoft Foundry. Foundry agents are bounded leaf workers; a workflow runtime is the deterministic spine; policy gates precede approval and execution; and controlled tools are the only path to a business system.Microsoft Foundry 上的参考架构。Foundry 智能体是有边界的叶片执行者；工作流运行时是确定性骨干；策略门禁位于审批和执行之前；受控工具是通往业务系统的唯一路径。图 2：Microsoft Foundry 上的参考架构。Foundry 智能体是有边界的叶片执行者；工作流运行时是确定性骨干；策略门禁位于审批和执行之前；受控工具是通往业务系统的唯一路径。

Layer 1: The workflow spine第一层：工作流骨干

This is the deterministic owner of the process. Implement it with Microsoft Agent Framework workflows, Azure Logic Apps, Durable Functions, or another deterministic orchestration runtime, depending on your engineering model.这是流程的确定性所有者。根据你的工程模型，使用 Microsoft Agent Framework 工作流、Azure Logic Apps、Durable Functions 或其他确定性编排运行时来实现它。

One architectural principle matters more than the specific runtime: the design centre should be a versioned workflow definition or a code-first orchestration layer, something you can diff, review, test, and roll back. Visual authoring surfaces are excellent for prototyping, but authoring surfaces evolve and get deprecated. A workflow definition under source control survives that; a canvas-only design does not.有一个架构原则比具体的运行时更重要：设计中心应当是版本化的工作流定义或代码优先的编排层，即你可以进行差异对比、审查、测试和回滚的内容。可视化创作界面非常适合原型设计，但创作界面会演进并被弃用。受源代码版本控制的工作流定义可以长久存续；仅基于画布的设计则不然。

Define your states explicitly:显式定义你的状态：

Submitted → Classified → PolicyChecked → ApprovalRequired → Approved → PayloadPrepared → Executed → Verified → Closed, plus Rejected and Exception.已提交 → 已分类 → 已策略检查 → 需审批 → 已批准 → 已准备载荷 → 已执行 → 已验证 → 已关闭，外加“已拒绝”和“异常”状态。

Then give every transition a deterministic guard:然后为每个转换设置一个确定性的守卫（Guard）：

Submitted → Classified
  requires: classification_result.schema_valid == true

Classified → ApprovalRequired
  requires: risk == "high" OR action_type == "privileged_access"

ApprovalRequired → Approved
  requires: approval.status == "approved"
            AND approval.approver_id is valid
            AND approval.timestamp exists

Approved → Executed
  requires: idempotency_key exists
            AND execution_lock acquired
            AND payload.validated == true

The workflow owns these transitions. Not the agent.工作流拥有这些转换，而不是智能体。

Layer 2: Bounded agent leaves第二层：有边界的智能体叶片

Each leaf does exactly one job, with one narrow context and the minimum permissions to do it.每个叶片只做一件事，拥有一个狭窄的上下文和执行任务所需的最小权限。

In Foundry these can be prompt agents when the task is configuration-driven, or hosted code agents when you need custom logic, state handling, or a specific execution model while still using Foundry models and tools.在 Foundry 中，当任务由配置驱动时，这些可以是提示词智能体；当你需要自定义逻辑、状态处理或特定执行模型，同时仍使用 Foundry 模型和工具时，可以使用托管代码智能体。

The contract is the control. Any leaf whose output feeds the spine must return structured, schema-validated output, never free-form prose:契约即控制。任何输出接入骨干的叶片都必须返回结构化、经过模式验证的输出，绝不能是自由格式的文本：

{
  "request_type": "privileged_access",
  "business_justification_present": true,
  "target_system": "finance_reporting_database",
  "requested_duration_hours": 8,
  "risk_level": "high",
  "requires_human_approval": true,
  "confidence": 0.91,
  "missing_fields": []
}

The workflow validates that schema. If validation fails, the workflow requests clarification or routes to exception handling. It does not let the agent improvise. The rule is simple: if the spine cannot validate the output, that output cannot influence the next transition.工作流会验证该模式。如果验证失败，工作流会请求澄清或路由到异常处理。它不允许智能体临场发挥。规则很简单：如果骨干无法验证输出，该输出就不能影响下一次转换。

Layer 3: Policy and guardrail gates第三层：策略和护栏门禁

Business policy and AI safety are different controls, and conflating them is a recurring design error.业务策略和 AI 安全是不同的控制点，将它们混为一谈是一个反复出现的设计错误。

Foundry guardrails and controls address AI safety and security risks: unsafe content, prompt injection, personal information exposure with intervention points at user input, model output, and, for agents, tool call and tool response. Foundry 护栏和控制措施解决了 AI 安全和合规风险：不安全内容、提示词注入、个人信息泄露，并在用户输入、模型输出以及智能体的工具调用和响应处设置了干预点。

But do not encode enterprise approval logic in prompts or safety filters. Business policy belongs in deterministic controls: Azure Policy, policy-as-code, a rules engine, service catalogue rules, entitlement policies, an approval matrix, ITSM workflow rules, or domain APIs.但不要将企业审批逻辑编码在提示词或安全过滤器中。业务策略属于确定性控制范畴：Azure Policy、策略即代码、规则引擎、服务目录规则、授权策略、审批矩阵、ITSM 工作流规则或领域 API。

The policy gate answers questions a model should never be trusted to answer alone:策略门禁回答了那些模型绝不应被信任单独回答的问题：

• Can this request proceed without approval?此请求能否在未经审批的情况下继续？
• Who is allowed to approve it?谁有权批准它？
• Is this action permitted for this user?此操作对该用户是否被允许？
• Is the target resource in scope, and the duration within policy?目标资源是否在范围内，持续时间是否符合策略？
• Is this a break-glass scenario?这是一个紧急情况（break-glass）场景吗？

An agent can explain the policy. The policy system decides.智能体可以解释策略，但由策略系统来决定。

Layer 4: The controlled action plane第四层：受控操作平面

This is where real-world change happens, so this is where the architecture must be strictest. Granting access, closing incidents, updating records, triggering deployments, approving procurement, all of it goes through controlled tools, never through free-form agent autonomy.这是现实世界发生变更的地方，因此架构必须最为严格。授予权限、关闭事件、更新记录、触发部署、批准采购，所有这些都必须通过受控工具进行，绝不能通过自由格式的智能体自主行为完成。

Foundry Agent Service supports built-in tools, custom functions, and MCP servers, with authentication via key-based access, Microsoft Entra managed identity, OAuth On-Behalf-Of, or unauthenticated access where appropriate.Foundry Agent Service 支持内置工具、自定义函数和 MCP 服务器，通过基于密钥的访问、Microsoft Entra 托管身份、OAuth On-Behalf-Of 或适当的非认证访问进行身份验证。

Wrap every action in a tool that enforces an explicit input schema, required fields, an idempotency key, caller identity, an approval reference, a correlation ID, a retry policy, a timeout, and deterministic success/failure responses.将每个操作封装在一个工具中，该工具强制执行显式的输入模式、必填字段、幂等性密钥、调用者身份、审批引用、关联 ID、重试策略、超时设置以及确定性的成功/失败响应。

The execution tool must reject this:执行工具必须拒绝这种情况：

{
  "action": "grant access",
  "details": "finance database admin for a while"
}

And require this:并要求这种格式：

{
  "ticket_id": "INC1234567",
  "request_id": "REQ98765",
  "target_system_id": "finance-reporting-db-prod",
  "principal_id": "user-guid",
  "role_id": "temporary-admin",
  "duration_hours": 8,
  "approval_id": "APR456789",
  "idempotency_key": "REQ98765-finance-reporting-db-prod-temporary-admin",
  "requested_by": "user-guid",
  "approved_by": "manager-guid"
}

If the payload is incomplete, the tool rejects it. The agent does not get a second chance to guess.如果载荷不完整，工具会拒绝它。智能体没有第二次猜测的机会。

Make tools boring and strict: validate input, reject ambiguity, return structured errors, enforce authorization, support idempotency, log correlation IDs, and never infer missing business data. Enterprise reliability is won here, in unglamorous code.让工具变得枯燥而严格：验证输入、拒绝歧义、返回结构化错误、强制执行授权、支持幂等性、记录关联 ID，并且绝不推断缺失的业务数据。企业可靠性正是赢在这些平淡无奇的代码中。

5. Five design mistakes to correct now5. 现在需要纠正的五个设计错误

Most failed multi-agent prototypes are not under-instrumented. They are under-designed. The five most common corrections:大多数失败的多智能体原型并非缺乏监测，而是设计不足。以下是五个最常见的修正建议：

Add a specialist agent only when it materially improves capability isolation, policy isolation, prompt clarity, or trace legibility: not simply because a task can be split.仅在确实能改善能力隔离、策略隔离、提示词清晰度或追踪可读性时才添加专家智能体，而不是仅仅因为任务可以拆分就添加。

6. A six-step implementation checklist6. 六步实施清单

1. Map the process before you name a single agent. For every step, classify it and assign an owner:

   Step type	Example	Owner
   Deterministic	Check the approval matrix	Workflow spine
   Agentic	Classify the ticket	Agent leaf
   Human	Approve privileged access	Approver
   Action	Grant access	Controlled tool
   Verification	Confirm access expires	Workflow spine

   If a step must be reproducible, auditable, or policy-bound, it belongs in the spine.如果一个步骤必须是可重现、可审计或受策略约束的，它就属于骨干层。

2. Define the state object explicitly. Every workflow needs durable, inspectable state:显式定义状态对象。每个工作流都需要持久且可检查的状态：

   {
     "workflow_id": "",
     "ticket_id": "",
     "current_state": "",
     "request_type": "",
     "risk_level": "",
     "required_approvals": [],
     "approval_status": "",
     "action_payload": {},
     "execution_status": "",
     "verification_status": "",
     "exception_reason": "",
     "correlation_id": ""
   }
   

   No agent should hold private state that determines the business outcome.任何智能体都不应持有决定业务结果的私有状态。

3.  Make every agent contract testable. For each leaf, specify the input schema, output schema, allowed tools, forbidden actions, confidence handling, error behaviour, and escalation behaviour, then build an evaluation set per leaf, not per system.使每个智能体契约都可测试。对于每个叶片，指定输入模式、输出模式、允许的工具、禁止的操作、置信度处理、错误行为和升级行为，然后为每个叶片（而非每个系统）构建一套评估集。
4. Put approval before execution, not after explanation. Human-in-the-loop is not a courteous notification after the fact; it is a blocking gate before sensitive execution. Agent Framework orchestrations support this through approval-required tools and request-info interactions. Use it for privileged access, production changes, financial approvals, customer-impacting actions, security exceptions, external communications, and any irreversible update.将审批置于执行之前，而非解释之后。人工介入（Human-in-the-loop）不是事后礼貌的通知，而是敏感执行前的阻塞门禁。Agent Framework 编排通过“需审批工具”和“请求信息交互”支持这一点。请将其用于特权访问、生产变更、财务审批、影响客户的操作、安全例外、外部通信以及任何不可逆的更新。
5. Verify against the system of record. A successful API response is not proof. Read the state back and confirm the change matches intent, including that time-bound access actually expires.根据记录系统进行验证。成功的 API 响应不是证明。回读状态并确认变更符合意图，包括确保有时限的访问权限确实会过期。
6. Choose the implementation path by risk, not by how "agentic" it feels. 

   Requirement	Recommended path
   Simple bounded agent on a managed runtime	Foundry prompt agent
   Custom agent logic or framework code	Agent Framework with Foundry models and tools
   Code-first production orchestration	Agent Framework workflow on managed compute
   Visual business-process orchestration	Azure Logic Apps calling Foundry agents
   Cross-agent interoperability	Agent-to-agent delegation where lightweight handoff is sufficient
   Enterprise safety controls	Foundry guardrails plus deterministic policy gates

7. The production boundary7. 生产边界

The next generation of enterprise automation will not be won by the team with the most agents. It will be won by the team that knows where not to use one.下一代企业自动化不会由拥有最多智能体的团队获胜，而是由知道在何处不使用智能体的团队获胜。

Multi-agent systems are genuinely powerful when they decompose expertise. They become dangerous when they replace workflow control. For tickets, approvals, onboarding, incident response, procurement, and finance operations, the boundary has to be explicit:多智能体系统在分解专业知识时确实非常强大。但当它们取代工作流控制时，就会变得危险。对于工单、审批、入职、事件响应、采购和财务运营，边界必须是显式的：

**The workflow owns the process.**工作流拥有流程。

The policy owns the permission.策略拥有权限。

The tool owns the action.工具拥有操作。

The agent owns only the reasoning task it was explicitly assigned.**智能体只拥有被明确分配的推理任务。**

That is the production boundary. That is how multi-agent automation becomes safe enough for enterprise scale.这就是生产边界。这就是多智能体自动化如何变得足以满足企业规模需求的方式。

And that is the shift customers need now, not more autonomous agents, but controlled autonomy: deterministic where the business requires trust, agentic where intelligence creates value.这正是客户现在需要的转变：不是更多的自主智能体，而是受控的自主性——在业务需要信任的地方保持确定性，在智能创造价值的地方发挥智能体作用。

Try it this week本周尝试一下

Pick one workflow you have already automated with agents, and do three things:挑选一个你已经用智能体自动化的工作流，并做三件事：

1. Draw its state machine on one page. If you cannot, the process has no owner.在一页纸上画出它的状态机。如果做不到，说明该流程没有所有者。
2. Find every irreversible action and confirm a deterministic guard sits in front of it — in code, not in a prompt.找到每一个不可逆的操作，并确认其前方有一个确定性的守卫——是在代码中，而不是在提示词里。
3. Replay one tool call twice in a test environment. If the business system changes twice, add an idempotency key today.在测试环境中重放一次工具调用两次。如果业务系统发生了两次变更，请立即添加幂等性密钥。

Then build it properly:然后正确地构建它：

• Microsoft Foundry — learn.microsoft.com/azure/foundryMicrosoft Foundry — learn.microsoft.com/azure/foundry
• Foundry Agent Service overview — learn.microsoft.com/azure/foundry/agents/overviewFoundry Agent Service 概览 — learn.microsoft.com/azure/foundry/agents/overview
• Microsoft Agent Framework — learn.microsoft.com/agent-framework · github.com/microsoft/agent-frameworkMicrosoft Agent Framework — learn.microsoft.com/agent-framework · github.com/microsoft/agent-framework
• Orchestration patterns — sequential, concurrent, handoff, group chat, magentic编排模式 — 顺序、并发、移交、群聊、magentic
• Human-in-the-loop workflows — learn.microsoft.com/agent-framework/workflows/human-in-the-loop人工介入工作流 — learn.microsoft.com/agent-framework/workflows/human-in-the-loop
• Guardrails and controls in Foundry — learn.microsoft.com/azure/foundry/guardrailsFoundry 中的护栏和控制 — learn.microsoft.com/azure/foundry/guardrails
• AI agent orchestration patterns (Azure Architecture Center) — learn.microsoft.com/azure/architecture/ai-ml/guide/ai-agent-design-patternsAI 智能体编排模式 (Azure 架构中心) — learn.microsoft.com/azure/architecture/ai-ml/guide/ai-agent-design-patterns

I'd like to hear from you. If you have shipped a multi-agent workflow into production, tell me in the comments where you drew the line between the spine and the leaves, and where that line turned out to be in the wrong place.我很想听听你的想法。如果你已经将多智能体工作流投入生产，请在评论中告诉我你在哪里划定了骨干与叶片的界线，以及那条线后来被证明在什么地方放错了位置。