In 2023, Guan Zhen was still giving lectures on smart factories to manufacturing enterprises. During an on-site stay at a factory, the person in charge asked him: "Teacher Guan, you explain it very well, but what use is this to me?"
What the other side asked was specific: when a batch of materials hasn't arrived, should the production line switch over or wait? How much downtime loss can predictive maintenance reduce, and is it worth the investment? He couldn't answer at the time.
On November 14 this year, 21st Century Business Herald published his entrepreneurial story. Guan Zhen worked at Microsoft for 19 years and left in 2023. In January 2024, he founded Zhiyong Kaiwu in Guangzhou, specializing in industrial AI agents. The company completed a nearly 100 million yuan Angel+ funding round in March 2026, and in 2025 it served more than ten clients with average customer spend in the millions of yuan.
What I care about is the way he solves problems, because that is exactly the part that most companies skip when doing AI projects.
1. There are four hurdles to clear before taking up the post; miss one and you're an intern
Zhiyong Kaiwu does not build general-purpose AI assistants; it builds for roles: AI production schedulers, quotation clerks, customs declarers, reconciliation clerks, and equipment inspection engineers. This entry point looks narrow, but it actually saves a lot of trouble—roles have clear inputs, outputs, and acceptance criteria.
According to their design, for a digital employee to officially take up the post, it must go through four steps: system integration, injection of role-specific standard operating procedures, configuration of hard constraints and on-site rules, and calibration based on historical data.
I'll translate it into terms that Party A can understand:
| This level | Things to submit | What happens if it's not done? |
|---|---|---|
| System integration | Interface list, field mapping, refresh frequency | The number read is expired |
| Position SOP Injection | How should this position be assessed, what should be checked first, and under what circumstances should it be reported? | The reply is like an encyclopedia and doesn't address the specific issue. |
| Hard constraint configuration | Capacity, shifts, minimum batch size, substitute material rules | The plan provided cannot be implemented |
| Historical Data Calibration | Compare by replaying real orders from the past three months | It went wrong on the first day of launch, and no one dared to use it |
Behind the second level there is a technical piece called the industrial semantic engine. It handles problems like this: the same material has one code in the supplier system and another code in the factory ERP; two fields have the same name but different granularity. If these are not aligned, the agent will make correct reasoning on wrong data—the conclusion is logically sound, but the premises are entirely wrong. This kind of error is the hardest to spot, because it looks particularly smooth.
II. Let the large model produce rules, and let the kernel produce plans
This is one of their most interesting design decisions. The large model does not directly generate the final production plan; it is only responsible for understanding requirements and generating rules; the plan itself is computed by a deterministic kernel based on established constraints.
Why take it apart?
Production scheduling work like this has a characteristic: the result must be explainable and reproducible. When the workshop supervisor asks "Why is this order scheduled ahead?", you cannot answer "The model thinks so." Next week, when the same set of conditions comes in, the calculated order should be the same; otherwise, no one would dare write it into a delivery commitment.
And large models happen to be bad at both. They are good at understanding a vague requirement, such as 'the customer is pressing for delivery, and only half of this batch of material is available,' and then turning that sentence into an executable rule. Rules are their job; solving is not.
This has a direct implication for companies using Odoo: most of the constraints that the deterministic core needs to compute are probably already in your system—they just aren't fully configured.
- Capacity: the capacity and efficiency factor on mrp.workcenter, as well as the shift calendar in resource.calendar. If no holidays are configured in the calendar, the generated plan will inexplicably have a few extra days.
- Material: the usage and loss rate in mrp.bom. The usage is written as one set, but the actual quantity requisitioned is one and a half sets; no algorithm can calculate it accurately.
- Replenishment: the minimum stock, maximum stock, and replenishment cycle of stock.warehouse.orderpoint. If these three numbers are inaccurate, the replenishment plan is just guesswork.
- Operation: the operation time and setup time of mrp.routing.workcenter. If left blank here, scheduling can only be done based on ideal conditions.
These parameters share one thing in common: filling them in is tedious and has nothing to do with AI, but without them, the model can only give "suggestions," not "plans." Many companies think they are doing AI projects, when in fact what they lack is a round of basic data organization.
The reverse is also true: If you don't plan to configure all these parameters, then don't build a scheduling agent yet. It will give you a Gantt chart that looks very professional, then fail the first time there's a rush order, and then everyone goes back to using Excel.
Three, when it comes to issuing employee IDs, the logic of policy and enterprises is the same
On November 13, the Ministry of Industry and Information Technology issued the "Notice on Strengthening Network Access Management of Agent Terminal Devices." The document governs mobile phones, tablets, and wearable devices with pre-installed AI agents, which are far removed from factories, but several requirements in it can be carried over verbatim to enterprise intranets:
- Identity.The intelligent agents used on terminals should be equipped with a unique identity code by referring to the series of national standards for agent interconnection. In enterprise scenarios: each agent must have a dedicated account and be able to answer "on whose behalf it acts".
- Changes. Major changes to terminals must be reported to the Ministry of Industry and Information Technology; to upgrade an agent via OTA, you must first submit a plan and then a report, and only after expert evaluation can the service be officially provided. Enterprises don't have an MIIT, but they do have audits — "Was this agent's prompt changed last month? Was it re-verified after the change?" Sooner or later, someone will ask this question.
- Authorization. App distribution platforms should encourage developers to declare via electronic signature whether they consent to agent invocation; if no declaration is made, invocation must not be forced. In enterprises, the corresponding concept is permission boundaries: which tables it can read and which documents it can modify must be signed off by someone.
- Compatibility. The product settings page must publicly disclose the terminal models that have completed adaptation, and must not provide downloads for incompatible models. The Enterprise Edition corresponds to "which version, which company, and which chart of accounts this agent has been verified under."
On the same day, Yonyou released YonAIG, splitting AI governance into six domains: observability, operations, context, evaluation, O&M, and security. Among them, "full-lifecycle operations" refers to the management chain from creation, identity configuration, authorization, and onboarding to retirement; "observability" can show the call tree of a single request—execution steps, latency, errors, and consumption; "evaluation" selects data according to sampling rules, asynchronously scores it with large models or code evaluators, attaches the scores back to records, and re-verifies after configuration changes.
Vendors are building products, enterprises are filling in ledgers, and regulators are setting rules—all three are talking about the same thing: an agent needs a verifiable identity and a verifiable history.
| Things to keep | How to implement in Odoo | Why |
|---|---|---|
| Dedicated account | An independent res.users, with only the necessary permission groups assigned | If an incident occurs, it can be traced to a specific identity |
| What can be seen | ir.model.access plus ir.rule, together with company context | Starting from Odoo 20, it is unified as ir.access, the determination method has changed, and it needs to be retested |
| What can be changed | Only expose a limited set of server actions or tools | The model can only request dishes that are on the menu |
| What was changed? | Tracking of fields with tracking=True in mail.thread | Who changed the delivery date from the 10th to the 25th, and when? |
| Ran a few times | Odoo 20's automation chat keeps a record of each automated run | If problems occur, they can be replayed and corrected |
A pitfall that must be called out: sudo(). In Odoo, writing code with sudo() can bypass all permission checks, and many custom modules do this to save trouble. If an agent runs on this kind of code, all the permissions you set in the UI are just decoration. Before doing an AI project, it’s worth searching globally for this term first.
IV. Replicating It on a Second Line Is the Real Test
Luxshare Group is the client with the deepest cooperation with Zhiyong Kaiwu. In August 2025, the two parties jointly built an AI innovation laboratory at Lijing Innovation within the group system, and the related results are being replicated to other business units within the group.
This sentence is where the true weight of this case lies. Getting a digital employee working on one production line depends on the patience of on-site engineers; whether it can be replicated to the tenth line depends on the product.
The real-world obstacles are made very clear in the report: different enterprises use different systems, and their business rules also differ. Some factories have a full IT department and can work together on integration; others do not even have standard interfaces and can only collaborate by regularly exporting data files. This means that even if two enterprises need the same type of AI for a given job role, their configurations may not be interchangeable.
Guan Zhen's point is that some complex work that used to take a full day can now be completed in 7 minutes—on the premise that accuracy meets delivery requirements. Those two words, 'on the premise,' are more worth remembering than the 7 minutes—it is actually an acceptance criterion, not a promotional slogan.
The financials also reveal the stage. In 2025, it served more than ten clients, with an average order value in the millions; in 2026, contract value is trending toward tenfold growth. But the report itself added a caveat: growth in contract value does not mean revenue and profit grow in tandem. The more clients there are, the more whether delivery can be standardized determines what kind of business this is.
This statement holds true for everyone doing AI delivery. Whether it can be replicated to a second client determines whether it is a product or a project. And the prerequisite for replication is that those tedious things—field mapping, SOPs, hard constraints, replay data—have all been accumulated into assets.
V. The place of people is not in technical solutions
There is a passage in the report that I think project managers should read even more than the technical section.
Zhiyong Kaiwu once deployed AI-assisted design tools for an enterprise, and the efficiency improvement was obvious, but the design department was initially unwilling to use them. Employees worried that their positions would be replaced, and also worried that after their years of accumulated experience was extracted by the system, they would lose their competitive advantage.
Such concerns cannot be dispelled by a single training session. The final approach was to redefine job boundaries together with the client: AI takes on repetitive execution work, while people handle exceptions and final decisions.
This arrangement sounds like a compromise, but it is actually the only workable division of labor. Because exception handling is precisely the kind of work that requires the experience that has been 'extracted away by the system.' The experience has not disappeared; it has moved to a different use case—from being repeated ten times a day to making judgments three times a day.
VI. If you are going to take action, do three things first
1. Give each agent a dedicated account and a role description. The account should clearly specify the permission group, and the description should clearly state what it can read, what it can change, and under what circumstances it must be handed over to a human. This description is the basis for all subsequent acceptance checks.
2. First put the hard constraints into parameters, then discuss having AI generate plans. Capacity, shift calendar, BOM usage, replenishment rules, and process times—if these five items are not properly aligned, do a data organization project first, not an agent project.
3. Use historical orders for an onboarding exam. Play back last month's real production orders, compare the scheduling results with the manual schedules made at the time, and examine item by item where the differences lie. If the accuracy does not meet the standard, do not issue an employee ID; let them work as an assistant first. This is more reliable than any POC demonstration.
Back to the factory manager's question: a batch of materials hasn't arrived—should we switch the line or wait?
AI can't answer this question unless someone first turns the cost of switching lines, the default risk of waiting, the time required to change over equipment, and each customer's escalation level into numbers the system can calculate. Once all of that is in place, the answer is really just computed—no "intelligence" needed.
The model's job is to understand that vague sentence. The rest still depends on people writing the rules clearly.
Sources: 21st Century Business Herald, "AI Enters the Factory Floor: Zhiyong Kaiwu Takes On Scale" (2026-11-14, republished by Sina Finance); Ministry of Industry and Information Technology, "Notice on Strengthening the Network Access Management of Agent Terminal Devices" (2026-11-13); China Economic Net, "Yonyou BIP Enterprise AI Governance and Operations Platform" (2026-11-13).
Zhongdi Information · Enterprise Management Digitalization Observations · Odoo fields and model names in this article follow Odoo 19/20.
